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ABSTRACT 



The Marine Air Command and Control System execution of Direct Air Support 
is based on the concept of centralized command and decentralized control. It is 
completed manually using standardized procedures and controls to ensure responsiveness 
in highly dynamic situations. This thesis investigates the issues in developing and 
implementing an automated database application for receiving, processing, disseminating, 
and recording information as it pertains to the Air Tasking Order within the Direct Air 
Support Center. A relational database design is proposed using Entity-Relationship 
modeling. A simple prototype of the system is implemented in dB ASE IV to demonstrate 
proof of concept. The major benefit of the database approach is that databases are 
dynamic and can evolve with changing needs. 
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1. INTRODUCTION 



A. BACKGROUND 

Information has always been the most important resource in command and control 
decisions. Unfortunately, communication has been viewed as a distant relative of the 
military profession. It is only in the last couple of decades that information systems to 
support the command, control and communication processes have been recognized in their 
own right by the military. Technological advances in the development of digital 
techniques for the representation and processing of information, and microelectronics have 
led to the fulfillment of long existing information requirements. Automated 
communications and information systems have enabled decision makers to cope 
effectively with the complexity of command and control on the battlefield. 

The Marine Air Command and Control System (MACCS) execution of Direct Air 
Support is based on the concept of centralized command and decentralized control. It is 
completed manually using standardized procedures and controls to ensure responsiveness 
in a highly dynamic situation. Based on the information contained in the Draft 
Operational Requirements Document (ORD) for the Direct Air Support Central, Marine 
Corps Combat Development Command identified operational deficiencies in the data 
processing capabilities of the Direct Air Support Center (DASC). The DASC requires an 
automated message and information handling capability to exchange, store, display, and 
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manipulate digital information using established Marine Tactical Systems and Message 
Text Format (MTS/MTF) standards. 

This thesis investigates the issues in developing and implementing a database 
processing system for receiving, processing, disseminating, and recording information 
required by the DASC as it pertains to the Air Tasking Order (ATO). Background of the 
MACCS, DASC functions, the ATO cycle, and lessons learned from Operation Desert 
Stomi are discussed. Application of an integrated Database Management System (DBMS) 
within the DASC will be explored addressing system and joint inter-operabUity 
requirements/problems. Man-machine interface will be stressed in the DBMS. The 
potential use of this system will be researched to improve the efficiency and effectiveness 
of information flow and decision making within the DASC, the MACCS, and the Fire 
Support Coordination Center (FSCC). 

B. SCOPE 

The focus of this thesis is a system requirements review of an integrated DBMS for 
the receiving, processing, disseminating, and recording of the ATO in the DASC. 
Research is specifically intended to model a system that uses available data in 
standardized format to budd a database, query the database, and then utilize the 
information to; (1) provide information to decision makers, (2) disseminate information 
to those who require it, (3) add and subtract information within the database. Research 
will cover database architecture in an integrated DBMS to include consideration in man- 
machine interface. 
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C. THESIS OBJECTIVES 



The primary objective of the thesis is to identify the system and information 
requirements for a database processing application that automates the ATO functions 
within the DASC. This will entaU the following steps: 

1. Determine the feeisibility of automating the ATO functions within the DASC. 

2. Demonstrate the potential to improve information flow and decision making within 
the DASC. 

3. Highlight problem areas in developing and implementing a DBMS for use in the 
DASC. 

4. Translate the user defined data requirements into a conceptual model, and design 
and buUd a database using that model. 

D. RESEARCH QUESTIONS 

There are several approaches to implement a database processing application. The 
primary research question is to determine the information requirements for a database 
application and generate a database design that fulfills the determined requirements. In 
support of the primary question, the thesis will identify the system requirements of an 
automated database and the design issues to be addressed in modeling the proposed 
system. 

E. LITERATURE REVIEW AND METHODOLOGY 

Background knowledge on the subject area was obtained through research into 
technical reports, academic publications, and a course on relational databases. The 
doctrinal and operational knowledge was gained from doctrinal publications, technical 
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reports, DASC project documentation, and interviews with Marines in the aix support 
control community. 

The methodology used in this thesis generally follows the application development 
process outlined by Kroenke and Dolan (1988, p. 75-82) which consists of five phases: 

1. The definition phase attempts to define the scope of the project. 

2. The requirements phase determines as specifically as possible what the new 
system must do. 

3. The evaluation phase studies alternative solutions to the requirements. 

4. The design phase involves creating the logical stmcture of the database. 

5. The implementation phase constructs the system according to the design. 

The scope of this thesis, as defined earlier, will look at the user requirements of a 
database processing system and model a database based on those requirements. The 
thesis will emphasize the design phase of the database based upon user defined 
requirements. Alternative database models wiU be addressed, and implementation of the 
design will be demonstrated on a specific microcomputer DBMS. 

F. SUMMARY OF FINDINGS 

The intent of relational database design is to increase the accessibility of database 
information to all users, rnmirriize redundancy, and allow for implementation of future 
applications to the DBMS. DBMS capabilities include mechanisms for displaying data 
through report generators and responding to "ad hoc" database queries. The relational 
model allows data independence, meaning that applications maintain more flexibility for 
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changes in the future than traditional file processing approaches. The database design 
developed by the entity-relationship approach is independent of and not restricted by the 
capabilities of any specific database system. It can be implemented in any relational 
DBMS environment. These concepts are important in the rapidly changing command and 
control environment. As users see how automation benefit decision making, their "need" 
for additional data and information processing will grow. 



G. ORGANIZATION OF THE STUDY 

The remainder of the thesis is organized as follows: 

* Chapter II provides the background to the MACCS to include the DASC functions 
and the ATO process. It lays the groundwork for demonstrating how a DBMS 
could improve the efficiency and effectiveness of decision making and information 
flow within the DASC. 

* Chapter HI explores the technology, man-machine interface, and system 
requirements of an automated infonnation system, and identifies the mformation 
flow requirements within the DASC. 

* Chapter TV explores database processing concepts to include design, tools, and 
techniques. 

* Chapter V presents a database design and implementation for the DASC application. 

* Chapter VI summarizes the benefits of a database processing approach for the 
DASC application. 
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II. MARINE AIR COMMAND AND CONTROL OPERATIONS 



A. GENERAL 

This chapter presents the fundamentals of control of aircraft and missiles, the 
MACCS, the DASC, the ATO cycle, and lessons learned from Operation Desert 
Stonn/Shield. The objective is to document the existing MACCS operational environment 
and eventually to identify the information flow requirements of the DASC with respect 
to the ATO. These requirements wUl be specified in Chapter III and serve as the basis 
for constmcting a database application based on the model discussed in Chapter IV. 

B. CONTROL OF AIRCRAFT AND MISSILES 

The capability to conduct successful tactical air operations is essential to the 
execution of military operations. The Marine Corps has organized an aviation combat 
arms capable of meeting the requirements of a flexible, responsive aviation combat 
element specifically tziilored to meet the anticipated tacticed situation. When combined 
with the requisite ground elements, the result is a balanced, self-sufficient, cohesive 
organization composed of air and ground arms known as the Marine Air-Ground Task 
Force (MAGTF). 

A task organized Aviation Combat Element (ACE) wUl normally be formed to fuUy 
support the MAGTF. The ACE supports the MAGTF with firepower and mobility it 
would not have otherwise. The ACE is not a permanent organization, but is organized 
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and equipped to provide the aviation functions required to accomplish the assigned 
mission. The tasks required to support the ACE’s mission fall into six functional 
categories: offensive air support, anti-air warfare, assault support, air reconnaissance, 
electronic warfare, and control of aircraft and missiles. 

Control of aircraft and missiles is defined as "the coordinated employment of 
facilities, equipment, communications, procedures, and personnel which allow the 
MAGTF commander to plan, direct, and control the efforts of the ACE to support the 
accomplisliment of the MAGTF’s mission." (FMFM 5-60, 1990, p. 1-1-2) According to 
JCS Pub 1 , command and control is "the exercise of authority and direction by a properly 
designated commander over assigned forces in the accomplishment of his mission." (JCS 
Pub 1, 1 April 1989, p. 76) Command includes "...the authority and responsibility for 
effectively employing available resources. ..for the accomplishment of assigned missions." 
(JCS Pub 1, 1 April 1989, p. 76) Control is defined as the "authority which may be less 
than full exercised by a commander over part of the activities of subordinate or other 
organizations." (JCS Pub 1, 1 April 1989, p. 87) Therefore "control of aircraft and 
missiles" is synonymous with "authority over aircraft and missiles." 

C. MARINE AIR COMMAND AND CONTROL SYSTEM 

The ACE commander exercises operational control over his assigned forces through 
the MACCS. The MACCS is an integral peui of the ACE’s organizational structure and 
consists of units specifically equipped with personnel, facilities, communications, and 
trained in procedures to support the command and control of all MAGTF air operations. 
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The MACCS operates under the principle of centralized command and decentralized 
control for maximum responsiveness to combat operations. 

The personnel and equipment required to establish the MACCS are contained 
primarily in the Marine Air Control Group (MACG) and its subordinate squadrons. The 
functional components (personnel and equipment) of the MACCS depicted in Figure 1 
include; 

* Tactical Air Command Center (TACC) is the senior MAGTF air command and 
control agency which serves as the operational command post of the tactical air 
commander (TAC), usually the ACE commander. The TAC and his staff execute 
the current air battle and plan for the future battle culminating in the publication of 
the Air Tasking Order (ATO) and appropriate fragmentation (FRAG) orders. 

* Sector Antiair Warfare Coordinator’s (SAAWC’s) facility, which is normally 
colocated with the Tactical Air Operations Center (TAOC), is the senior air defense 
battle manager for the ACE. It provides the interface between the TAOC and 
TACC. 

* TAOC and Early Waming/Control (EW/C) sites detect, identify, and control the 
intercept of hostile aircraft and missiles. 

* Direct Air Support Center (DASC) processes immediate air support requests, 
coordinates aircraft employment with other supporting arms, and controls aircraft 
transmitting its area of responsibility. A complete description of the DASC’s roles, 
tasks, inter-agency relationships and information needs will be discussed later. 

* Air Support Radar Team (ASRT) provides day/night all-weather control of aircraft 
operating in support of MAGTF operations. 

- Subordinate Command Posts (CPs)/Combat Operation Centers (COCs) provide the 
primary control agency from which Light Antiaircraft Missile (LAAM) and Low- 
altitude Air Defense (LAAD) Battalions can direct and control the HAWK and 
Stinger missile systems. 

* Marine Air Traffic Control Squadron (MATCS) Detachment provide continuous all- 
weather air traffic services for expeditionary airfields and remote landing sites. 
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• Airborne Control Agencies offer flexibility to operate either as an extension of the 
means of control to functional control agencies (Tactical Air Coordinator (Airborne) 
(TAC(A)), Helicopter Coordinator (Airborne) (HC(A))), in support of specific 
ground units (Forward Air Controller (Airborne) (FAC(A))), or in coordination of 
other aircraft (Refueling Area Coordinator (RAC)). 

• Tactical Air Control Parties (TACPs) are organic to the Ground Combat Element 
and provide air liaison to land forces and terminal control of aircraft. 

MACCS agencies have no control over aircraft or other units unless specifically 

delegated to them by the appropriate commander. Types of control that are usually 

delegated include: 

• Command. The TACC is the one MACCS agency that exercises command. 

• Air Direction. The authority to regulate the employment of air assets. 

- Air Control. The authority to direct the physical maneuver of air assets. 

• Airspace Control. The coordination, integration and regulation of airspace. 

• Terminal Control. A subset of control that applies to the delivery of ordnance, 
cargo, or personnel by aircraft. 

The MACCS will be tasked-organized to provide MAGTF commanders with the 
assets required for effective command, coordination, and control of aU MAGTF air 
operations. Interagency relationships between the MACCS elements can be defined as 
the type of control each agency exercises. Development of the ATO is a form of air 
direction that the ACE commander exercises through the TACC. Air control can be 
thought of as an instruction given to a pilot by a control agency to alter his course. 
Airspace control is the authority to direct aircraft so the best use is made of a defined 
area of responsibility. The DASC exercises both air control and airspace control when 
authority has been delegated to them. The DASC wiU receive air direction via the ATO 
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from the TACC. Figure 1 depicts the MACCS and its control relationships with the 
various agencies. 



D. DIRECT AIR SUPPORT CENTER 
1, Background 

The Direct Air Support Center is the principle air control agency responsible 
for the direction of air operations directly supporting ground forces. The DASC processes 
direct air support requests, controls aircraft in its area of responsibility, manages terminal 
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control agencies in support of the ground combat element (GCE), and coordinates air 
missions requiring integration with other supporting arms. 

The DASC functions in a decentralized mode of operation under the command 
of the TACC. It is normally the first major air control agency ashore and normally lands 
with the senior Fire Support Coordination Center (FSCC) during scheduled or on-call 
waves. It physically or electronically colocates with the senior FSCC and works closely 
with this agency to ensure the coordination of air support with other supporting arms. 
The DASC maintains the capability to operate during mobile combat situations by 
displacing by echelon to preserve operational continuity. The "echelon DASC" will have 
the capability to perform the same tasks as the main DASC. 

Functional positions within the DASC include directors and net operators. 
Directors interface with, and control aircraft. Net operator coordinate with agencies 
external to the DASC. The functions and tasks performed by the directors and net 
operators within the DASC is discussed next. 

2. Tasks 

The DASC provides direct air support functions for the MAGTF by performing 
the following tasks: 

• To receive fragmentary operation orders (FRAGOs) and ATOs from the TACC and 
coordinate preplanned scheduled direct air support. The ATO and FRAGOs are 
normally received on a daily basis but may be modified as changes occur. 
Information about these changes will normally come via the TACC. 

• To receive, process, and coordinates requests for immediate or on-call air support. 
These requests will normally originate from the supported ground combat element 
requesting tactical air, assault support, or medical evacuation. This is one of the 
most critical tasks performed by the DASC. 
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- To adjust preplanned scheduled aircraft and divert airborne assets based upon 
mission priority in coordination with the senior FSCC when delegated authority by 
the TAC. 

* To provide coordination in the execution of direct air support missions with other 
supporting arms through the appropriate FSCC. 

* To coordinate subordinate terminal control agencies as required. 

* To receive and disseminate pertinent tactical information reported by aircraft 
performing direct air support missions. 

- To provide aircraft and other air control agencies with advisory information for the 
safe conduct of flight. 

* To monitor, record, and display information on direct air support missions. 

* To maintain friendly and enemy ground situation displays, as necessary, to 
coordinate direct air support missions. 

* To provide information to other MACCS agencies concerning the friendly and 
enemy situation to include aircraft position. 

* To refer unresolved conflicts in supporting arms to the fire support coordinator and 
provide an operational point of contact to ensure air support is responsive to the 
tactical situation. 

3. Communication Links 

In order for the DASC to perform these tasks, rapid and reliable 
communication links must be maintained with agencies external to the DASC. The 
command and control connectivity between the DASC, the aircraft and these external 
agencies is accomplished by radio. The primary DASC interagency relationships depicted 
in Figure 2 include: 

* DASCA^ACC. The DASC is subordinate to the TACC and provides for 
decentralized control of direct air support missions including close air support 
(CAS), and assault support. The TAC will ideally delegate divert and on-call 
launch authority of aircraft to the DASC to ensure minimum response times to 
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MAGTF requirements. The TACC provides the DASC with appropriate ATOs, 
FRAGOs, aircraft call-signs, and aircraft availability. The DASC and the TACC 
exchange tactical information, intelligence, and the progress and effectiveness of 
direct air support missions. 

• DASC/FSCC. Since the FSCC is the final arbitrator for all supporting arm conflicts 
the DASC and FSCC maintain close ties. The DASC and FSCC must be able to 
exchange timely information on tactical information (fire support coordination 
measures, friendly/ enemy unit positions, etc.), pertinent intelligence data, status of 
immediate air support requests, bomb damage assessments, divert and on-call 
launch decisions, and other prearranged data items. 

* DASC/Antiair Warfare (AAW) Agencies. The DASC must be able to exchange 
tactical data information and pertinent friendly aircraft location with the appropriate 
AAW agencies (TAOC, LAAD/LAAM CPs). 

♦ DASC/Airbome Controllers. The DASC must coordinate and exchange information 
with airborne control agencies pertaining to their responsibilities. 
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• DASC/ASRT. The ASRT is a terminal control agency subordinate to the DASC 
and receives all tactical data information from the DASC. 

• DASC/TACPs. The DASC receives and processes immediate air support requests 
from the terminal controllers (Forward Air ControUers (FACs)) and apprises the 
TACPs and FACs of their status. 

• DASC/OTHERS. The DASC will establish and maintain communication links with 
other agencies as required. Examples of this include, MATCS, Remotely Piloted 
Vehicle (RPV) Receiving Station, and the Air Force Air Support Operations Center 
(ASOC). 

4. Current Operations 

The DASC is a flexible, communications intensive facility that may be 
configured to support a variety of tactical situations. It is presently a manual system 
using procedural control methods and voice communication to fulfill its tasks. 

The ATO is issued by the TACC and distributed to the MACCS elements on 
a daily basis. This ATO may or may not be a re-creation of the Air Force ATO. The 
means of distribution of the ATO may be via message traffic through a message center, 
courier, or local area network. Considerable time is then expended in processing and 
disseminating the ATO data within the DASC and retransmitting applicable ATO mission 
data to the ASRT or TACP’s. The DASC receives voice or message traffic whenever a 
change to the ATO occurs. 

Requests for immediate air support are transmitted from the TACPs to the 
DASC over the voice only Tactical Air Request (TAR) Net. All FSCCs monitor the TAR 
net and may disapprove, or by their silence, give consent to, the immediate air request 
(Figure 3). Upon receipt, the DASC will concurrently process the request, and coordinate 
mission planning with the colocated FSCC. The DASC will fulfill the request by 
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diverting lower priority airborne aircraft or by launching on-call missions. Each request 
requires manual completion of a specific form, must be posted on display boards, and 
transmitted to the TACC. Upon completion of the request, mission data is manually 
recorded on the form and disseminated to the TACC and FSCC. 

As all types of operational message traffic increases, the DASC’s operational 



mission data becomes less current because of the workload in manual processing, 
dissemination, transmission and posting of information. 




Figure 3. Immediate Air Requests 



E. AIR TASKING ORDER 

The ATO planning process for tactical air operations is a continuous activity that 
begins at the senior MAGTF level for the Marine Corps or the joint force theater level 
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in combined operations. The planning steps will be treated generically, using the Marine 
Corps as an example (Figure 4). The time sequence, usually 36 hours for the Meurine 
Corps, would be longer when considering the joint level. The planning sequence provides 
background on how the ATO is generated and transmitted by the TACC and received and 
processed by the DASC. 

The MAGTF commander develops the strategy and establishes the objectives for 
the conduct of military operations and apportions the available force to the various air 
tasks for a specific period of time. Apportionment is usually expressed as a percentage 
of total available assets assigned to the various missions (CAS, AAW, etc.) or in terms 
of priority by mission or geographic area. This apportionment guidance is based on the 
recommendation from his component commanders (ACE, GCE, etc.) and is promulgated 
in the apportionment guidance. 

The ACE commander reviews his assets and allocates them in terms of sorties 
according to actual number of aircraft by type for each mission category consistent with 
the apportionment guidance. The future battle cell (FBC) in the TACC is responsible for 
developing the detailed plans of the ATO based on the apportionment and allocation of 
resources. The ground combat element provides the FBC with a prioritized target list for 
air interdiction targets and any additional preplanned requests to include a needed 
preplanned/immediate missions mix. The FBC considers the weather, enemy threat, 
availability of assigned forces and weapons, and target selection when developing the 
plan. Sorties in excess of MAGTF direct support requirements will be provided to the 
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Joint Force Commander for joint force tasking. The results of this planning process are 
disseminated as the ATO. 

Although there is no specific format for the ATO, the ATO provides the mission 
details, special instructions, general information and remarks required by the subordinate 
units to execute their assigned tasks. The ATO will normally be transmitted in message 
text format (USMTF) or marine tactical standard (MTS). The USMTF ATO message is 
further discussed Chapter III and is listed in Appendix C. 

Upon receipt of the ATO, aircraft groups generate FRAGOs assigning specific 
missions to squadrons and aircrews. Control agencies review, manipulate, and manually 
record the ATO onto report in/out (RIO) forms/logs and time-lines in preparation of 
controlling and directing the aircraft. 



F. LESSONS LEARNED FROM OPERATION DESERT STORM 

The IDASC (Improved DASC) Users Conference was held 8-12 April, 1991 at 
Mare Island, Cahfomia following Operation Desert Storm primarily to "get a consensus 
of the jiir support control community on the priority and nature of proposed requirements 
(IDASC project)." (Report of Travel/Conference, 1 May 1991, p. 1) Receipt of the ATO 
was a main discussion item of the air support control community at this conference as the 
following item reflects: 

* "SUBJECT; RECEIPT OF THE ATO 

• DISCUSSION: The Joint ATO, issued by the Air Force was upwards of 700 pages 
long and originally was received via the Division Communications Center. Later, 
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Figure 4. ATO Planning Process 



it was scrubbed by the TACC and sent to the DASC via LAN. Received by the 
DASC on a UYQ-85, it arrived as two documents, a fixed wing and helicopter 
ATO. The scrubbed version, however, did not include other services aircraft. 
While the large joint version was stUl available via the communications center, 
significant effort was necessary to glean out the applicable missions from this 
unabridged version. While a standard MTF format was used, some Marines stated 
that some standardization still needed to be set down. 

• EvIPACT: The DASC needs the ATO in a timely manner and in a useful format. 
Consistent, successful receipt via the LAN on Desert Storm seems to suggest that 
this is a good way to receive the ATO provided that the LAN is available. The 
other ways of receiving the ATO (courier, teletype, tactical FAX) are still available 
if a LAN isn’t. 

• Ideally, the DASC would need to be capable of receiving the ATO either directly 
from the joint level or from the Marine Corps TACC. In either case we would like 
to be able to manipulate the ATO in such a form as to be readily usable to the 
aircraft directors, the SAD and anyone else who needs it. (Many man-hours are 
spent "busting the frag:" copying the applicable portions of the ATO onto RIO 
sheets and/or making up time-lines so that it is usable) 
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* If we have the luxury of receiving the ATO digitally, a manipulative program in the 
UYK-85 could be used to separate out helos from fixed wing, arrange the 
information into kinds of columns that we like to see, filter out unnecessary 
information, make up time lines to show mission groupings, and generally save time 
and effort. One Marine using such a program could prepare RIO sheets for the 
directors and time lines for the SAD in minutes. For record purposes, information 
could be quickly extracted by mission type, ordnance type, aircraft type, etc., and 
sent to the TACC without taking up a lot of valuable time..." (Desert Storm Initial 
Debrief Synopsis, 9 April 1991, p. 6) 

The users identified the following required capabilities during Phase II (selected 
automation) of the IDASC project in order of priority: 



1. Receive and print out the ATO in MTF or MTS format. 

2. Manipulate the ATO into formats desired by the user. 

3. Receive and print out PLRS information. 

4. Send, receive and print out DCT messages. 

5. Automatically record and file Tactical Air Request (TAR’s), Bomb 
Damage Assessments (BDA’s) and other DASC related information. 

6. Extract statistical information from automated files. 

G. SUMMARY 

It is necessary to realize that the Marine Air Command and Control System is 
fundamentally a tool that decision makers use. It is a collection of equipment, personnel, 
and procedures that help the ACE commander gather, process, and disseminate 
infomiation. Within the present DASC, coordination of air support requests with the 
FSCC, the receipt, storage, display, manipulation, and dissemination of the ATO and 
FRAGOs, and retrial and display of operational data are largely manual. The system is 
rapidly becoming deficient in its ability to perform its tasks. An increasing amount of 
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information has generated the need for selective automation of parts of the system. Given 
the current DASC and the related ATO operations, what zispects of the overall process can 
be automated effectively? The next chapter specifies requirements which address this 
question. 
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m. DASC/ATO REQUIREMENTS 



A. GENERAL 

This chapter discusses the following issues involved when designing a database 
processing system for the DASC: 

* information processing requirements 

* hardware concepts and problems in the battlefield environment 

* man-machine interface considerations 

* data communications 

* interoperability 

* system security issues 

Background information about the IDASC project will be smnmarized first to show 
the constraints and scope of the needed database application. Internal and external 
interaction requirements and constraints of the system wUl be briefly discussed to 
determine the demands placed on the design of the equipment and the applications. The 
information flow requirements discussed last will serve as a blueprint for database design 
and implementation addressed in Chapters IV and V. 

B. IDASC PROJECT SUMMARY 

The IDASC is the designation given to the AN/TSQ-155(V) operations shelter. The 
shelter houses the personnel and equipement required of the DASC to perform its mission. 
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To avoid confusion because of pending modifications, the IDASC will be referred to as 
the AN/TSQ-155 when in reference to the system or DASC when implying the 
operational function. The DASC supporting system prior to the AN/TSQ-155 was fielded 
during the 1960’s and was designated the AN/TSQ-122. The AN/TSQ-122 was unable 
to satisfy increasing operational requirements and was fully replaced in 1989 by the 
AN/rSQ-155. The acquisition was initiated to satisfy requirements exclusive to the U.S. 
Marine Corps. There was no joint or foreign service pauticipation. During May 1989, 
the Naval Electronics Systems Engineering Center (NAVELEXCEN) was tasked to act 
as the In-Service Engineering Agent (ISEA) for the IDASC improvement program. After 
reviewing operational effectiveness, it was determined that operational deficiencies existed 
and the Required Operational Capability for the DASC was revised leading to a phased 
system upgrade. 

Phase 1 modifications to the AN/TSQ-155 are near completion. Phase II (selected 
automation) and phase IH (downsizing/improved mobility) upgrades will be accomplished 
concurrently by coordinated design/developmental tasks that will create a new entity for 
the DASC, a vehicle mounted shelter with an integrated command post extension tent and 
equipment that will provide automated capability. The automated capability improvement 
will be compatible with and interchangeable between the "Mobile DASC" and the 
AN/rSQ-155. 

A primary goal is to populate the DASC with Non-Developmental Item (NDI) or 
off the shelf computer equipment and software. The system will use hardware from the 
Marine Tactical Command and Control System (MTACCS) Common Hardware System 
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(MCHS) and will consist of rugged computers capable of handling a large volume of 
information. The DASC computer terminal will be capable of interfacing with a variety 
of communications equipment to include tactical radios, tactical switches, tactical FAX, 
and tactical LANs. 

The DASC system will incorporate software from the MTACCS Common 
Application Support Software (MCASS). System software will provide the DASC with 
a set of automated tools to assist in the performance of its functions. These tools should 
have the following capabilities: word processing, message preparation and processing, 
tactical information database, digital message management system, overlay generation and 
distribution, database management system, database query capability, 3uid hard copy text 
and graphics. These tools will enable the DASC to fulfill the user requirements of 
updating, displaying, and controlling the ATO and DASC related information from 
automated files. Application software will reflect the specific requirements of the DASC 
and be capable of running on the system hardware and use system software. Additionally, 
each operator requires a position which provides a workstation and allows individual 
access to intercommunications and common display information. (Draft ROC, p. 11) 

C. BATTLEFIELD REQUIREMENTS 

The hardware and software used by the DASC must be able to operate in all combat 
environmental conditions. It must be capable of operating in a tent or open field while 
mounted in military vehicles, and be transportable with ruggedized canying/shipping 
boxes. Physical environment factors to be considered include temperature, humidity, sand 
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and dust, air pressure, shock and vibration, rain, fog, and salt water. Furthermore, 
electromagnetic pulse (EMP) and interference, as well as radiation security (TEMPEST) 
standards must be met. Finally materials used must be resistant to chemical agents and 
chemical decontaminants. Human factors engineering must be applied to allow human 
operators in all mission-oriented protective postures to use the machines in the battlefield 
environment. The size and weight of the components should allow for ’one-marine 
carry’. The system should have visual indicators and messages easily readable in all 
ambient light conditions. The storage hardware must be capable of rapid emergency 
destruction to enable protection of classified data. Redundancy both in data storage and 
power requirements must also be planned. These battlefield environmental constraints 
will have an effect on the physical design of the hardware as well as the architecture of 
the whole system including its interfaces. 

O. SYSTEM INTERFACES 

The DASC must interface with agencies internal and external to the MAGTF. In 
order to fulfill these requirements, numerous intra/interoperability interface networks have 
been constructed; however, some interoperability requirements are projected as future 
requirements. 

The system must also interface with the required MACCS and MTACCS agencies. 
Projected interoperability interfaces include elements of the Naval Tactical Air Control 
System (NTACS), the Air Force Tactical Air Control System (TACS), the Army 
Command and Control System (ACCS), and allied air support control units as required. 
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The DASC system will affect interoperability in accordance with the Marine Tactical 
System Technical Interface Design Plan (MTS TIPD) and United States Message Text 
Format (USMTF). 

1. Marine Tactical System 

The MTS TIDP provides USMC Tactical Data Systems (TDSs) with 
intraoperability message, data elements, and protocol standards. The interface design plan 
decomposes Marine Corps Command and Control Facilities (C2FACs) of the MTACCS 
interface requirements into specific data link protocol and message/data implementation 
requirements. It also provides the data element standard for data field identifiers (DFIs), 
data use identifiers (DUIs), and data items (DIs) that support the MTS standards. The 
message standards in volume IV of the TIDP contains approved Marine Corps messages 
with information on message purpose, structure, data content, and format. The 
transmission fonnat (physical order and sequence of the fields) are presented on text 
information sheets within the TIDP. The MTS Message Formatting protocol provides 
message formatting that allows the system to be independent of the communications 
system. 

2. Message Text Format 

The USMTF program is designed to provide a uniform reporting procedure to 
be used in all defense conditions and to reduce the time required to draft, transmit, 
analyze, interpret, and process messages. The message text format (MTF) program 
improves information exchange by producing messages which are both human readable 
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and machine compatible. The program also has the objective of facilitating the exchange 
of information between the United States and Allied commands and reducing or 
eliminating dual reporting by US units when they operate with Allied command/units. 
The MTF program describes what is in reality an artificial language with its own definite 
structure, vocabulary, and syntax. The MTF ATO message format is listed in Appendix 
C. 

3. Communications 

Communications requirement considerations include capacity, response time, 
connecting and addressing, integrity, control, security, and transmission medium. The 
demand for communication will not be constant but the demands for data transmission 
capacity and response time must be met by the communications system. Connecting and 
addressing protocols must provide a means for identifying the intended recipient of a 
transmission. The transmission medium must preserve the integrity of the information 
it handles. Control protocols must be applied to channel and transmission medium 
between computer-based information systems. The security of the information must be 
preserved by the communication system. Redundancy in the transmission medium must 
be planned. This redundancy may be single or multi-channel radio, satellite 
communications, copper cables or fiber optics. 
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E. MAN-MACHINE INTERFACE 



Rice states that "the design of the ... man-machine interface (MMI) will be crucial 
to the efficient working of the system ... it provides the user with a window through 
which he may view the system and a set of controls to enable him to drive it." (Rice, p. 
82) Simple interfaces consist of a way to insert/extract information into/from the system, 
and to direct the system what actions to take. The MMI includes the hardware and the 
software for this process. The dialogue used in this process determines how "user- 
friendly" the system is. 

Input devices consist of keyboards and pointing devices. A pointing device such 
as a tracker ball or mouse moves a symbol on the display to a desired position. Pointing 
to the desired position on the screen itself with a finger or instrument is another type of 
input. 

Output devices include either temporary or permanent display units. Temporary 
displays consist of visual display units such as cathode ray tubes (CRT), liquid crystal 
displays (LCD), gas plasma display, and projected displays. Permanent displays which 
deliver a hard copy may be either printers or plotters. Printers are usually limited to text 
or simple graphics while plotters can produce images along an x and y axis. Laser 
printers combine the qualities of both a printer and a plotter. 

Other interface technologies under consideration are voice recognition for input and 
speech synthesizers for output. 

The design of the dialogue between man and machine will determine how the user 
interacts with the system. The MMI should be easy to use for both the inexperienced and 
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the familiar user, consistent, and optimized for the task being performed. (Rice, p. 96) 
A context-sensitive "help" key which explains the task being performed is an example of 
this trait. Consistency standardization refers to the way tasks are to be performed. A 
simplified example of inconsistency would be imputing ’Y’ or ’N’ in one application 
program while requiring ’YES’ and ’NO’ in another. Pointing devices should also 
maintain consistent operations. Optimization for the task being performed means that the 
user should not have to access a large number of displays to perform his job. 

Styles of MMI that conform to the requirements above include a keyboard based 
MMI, a touchscreen based MMI, and the windows, icons, menus and pointer (WIMP) 
approach to MMI. (Rice, p. 98) Menu selection refers to a range of choices presented to 
the user on the screen. The input by the user wiU lead to other menus or to the task 
requiring performance such as entering form information. These layers of menus are 
referred to as the depth of the application and may be described as a tree structure. 
Experienced users should be able to jump between layers, while a user who finds himself 
confused about his location in the menu dialogue should be able to return directly to the 
main menu. 

Keyboard based MMI are useful in data entry systems. A menu can lead the user 
to the correct form and then a form layout can assist the user in entering information. 
Shaded areas ctin highlight required inputs. 

Touch screens can be interchanged or incorporated with keyboard based MMIs, 
using graphical representations that prompt the user to touch the screen for the desired 
result. 
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The WIMP approach to MMI offers benefits which include consistency and multiple 
tasking. Windows are an area of the screen dedicated to a particular task. Icons 
graphically represent a resource or action to be preformed. When combined, they 
approximate the way a user may organize his tasks. 

The following examples of consistency include retrieval and saving of documents. 
All files are opened by pointing to an associated icon. Saving a file is accomplished by 
’dragging’ it to a file cabinet icon and then clicking a button on the mouse to indicate the 
document is to be saved. 

Multiple tasking involves being able to work on two or more applications at the 
same time. For example, while working on a word processing document, the user may 
open a window, retrieve data from a spreadsheet and then ’cut and paste’ this information 
into the original document. This example of multiple tasking demonstrates one of the 
advantages of the WIMP or graphical user interface (GUI) approach to MMIs. 

The choice of MMI wiU be determined by the required tasks and battlefield 
environment. Because the users in the air support community are often resistant to 
automation, these design decisions are critical to the acceptance of the entire system. 
Automation must both improve efficiency through user friendliness, and provide useful 
information. MCTSSA, representing the user community, must stress the importance of 
user friendliness and insure user involvement with the designers, developers and 
programmers of the MMI. 
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F. INFORMATION FLOW REQUIREMENTS 



Although the DASC consists of many crew members performing separate functions, 
we will treat the DASC as a "black box" and concern ourselves with the external 
information flow of the DASC rather than the internal coordination of the DASC crew. 
The DASC crew wUl interact with different applications designed for their specific 
functions. The information flow of the DASC that pertains to the user requirements 
defined in Chapter II is depicted in Figure 5 and includes: the ATO, mission requests, 
mission status, aircraft status, and battle damage assessments. Each is considered in turn. 
The appropriate forms are displayed in Appendix 3. 




Figure 5. DASC Information Flow 
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1. ATO 



The ATO is received by the DASC daily. Updates or changes to the ATO can 
be received at any time. The MTS message includes the effective time period, tasked 
unit(s), and basic mission information: mission number, request number, priority, mission 
type, time on and off target, alert status, location, callsign, number and type of aircraft, 
ordanance type, IFF/SIF mode and code, and time and target location. 

2. Mission Status 

Mission status refers to the infonnation that an appropriate MTACCS agency 
sends or requests on aircraft assignment data. The status may pertain to preplanned, on- 
call, or immediate missions. The information may pertain to any data on the ATO. 

3. Mission Requests 

Requests to the DASC for direct air support can come in the form of tactical 
air requests or assault support requests. Voice communications discussed in current 
operations use the JTAR or ASR forms. MTF message standards utilize the Air Support 
Request (ABRSUPREQ) format. The DASC may assign subordinate controlling agencies 
mission data and brief the aircrew using the 9-line brief format. 

4. Aircraft Status 

Aircraft status/avadability reports are made to the DASC pertaining to aircraft 
in a strip alert status. If the DASC has launch authority of the aircraft, information would 
include number and type of aircraft available during specific time periods with specific 
ordnance and strip alert times. 
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5. Battle Damage Assessment 



The purpose of the BDA is to convey the pilots’ or controllers’ damage 
assessment, ordnance expended, and ordnance remaining. The DASC receives the 
infonnation and relays it to the appropriate MTACCS agency. 

6. Reports 

The DASC may be required to submit operational summary reports based on 
the operational events during a specified period. 

G. SUMMARY 

The DASC system requirements discussed in this chapter defined the computer 
hardware, software, security and communications considerations that require attention 
when designing systems that can survive on the battlefield. By establishing the 
infonnation exchange requirement of the users as applied to the ATO, we are now able 
to look at database processing alternatives for developing a database application for the 
DASC. 
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IV. DASC DATABASE APPLICATION 



A. GENERAL 

The user requirements and information flow discussed in the previous chapters will 
provide the basis for the logical database design developed in this chapter. The Entity- 
Relationship (E-R) approach is utilized to develop the logical database design. The data 
is normalized using an E-R modeling tool. The use of these methods will demonstrate 
the potential for designing and implementing a relational database application within the 
DASC. 

B. DATABASE OVERVIEW 

Database technology was developed to overcome the limitations of file processing 
systems. In database systems, all application data are stored in a single repository called 
a database. (Kroenke, p. 10) It is a collection of related data designed and built for a 
specific purpose, intended for use by a known group of users, representing some aspect 
of the real world. Database processing eliminates the dependency of programs on specific 
fUe formats which cannot be shared easily by other programs. DB processing allows 
different users to share the same data thus niinirnizing duplication and update problems 
caused by redundant data in file processing systems. Unlike file processing programs, 
database processing programs do not require file and record formats. (Kroenke, 1987, p. 
11) File formats are stored in the database and accessed by a database management 
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system (DBMS). This arrangement of data, called program/data independence, is the 
primary objective of a DBMS. 

Database applications are developed so users in different functional areas can 
retrieve information from a common database without interfering with one another. 
Database systems provide mechanisms for updating, displaying, and controlling the data. 

A database model is a representation of a physical database. It shows the physical 
files, the access paths between the files, and the data items in each file. Database models 
are defined by the way data is organized, stored, and manipulated. Traditional file 
processing systems use flat files where relations between files are defined by the 
application programmer. The emergence of DBMSs led to different concepts in database 
architecture, and the way data is linked to the database and the application. 

The primary database models are the hierarchical, network, and relational models. 
In the hierarchical and network models, the application programmer must know the 
physical structure in order to navigate through the database. This structure can become 
very complex to leam and is quite demanding on the user and/or programmer interacting 
with the database. The conceptual structure matches the physical structure tying the data 
to the application. This results in a high level of maintenance because changes in the 
application data requirements force changes in the defined data structures. (Brackett, 1987, 
p. 6) These weaknesses have led to a third method of data modeling based on relational 
theory. 

Relational database architecture is an environment in which data are viewed as 
tables, or relations,and multiple tables can be associated or related to one another based 
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on common data items or fields within die tables. The physical relationships are defined 
at execution time based on the application needs. This model contrasts with the 
hierarchial or network models which require pointers or links in each data record. Since 
there are no predefined relationships in relational databases, the structural detail is 
niinirnized. This results in lower database maintenance, m akin g it easier to control 
database changes, and provides flexibility by facilitating the definition of dynamic logical 
relationships (Brackett, 1987, p. 5-6). Reports or processes can be added without having 
to modify the structure, and changes made to a data item wiU be reflected in every related 
record. 

Knowledge of relational model terminology wiU assist in imderstanding the logical 
database design presented below. The relational data model files appear as flat files, or 
tables to the users. A relation is a table containing data about an entity or object that 
obeys certain rules. An entity is a real world thing. Each relation deals with a single 
entity and each row in the relation is an instance or occurrence of an entity. A tuple is 
a row in the table, an attribute is a column. There is no order to the tuples and attributes. 
Each attribute has a domain of values which can be assigned to any instance of an 
attribute. A key is a group of one or more attributes that uniquely identifies a row. The 
primary key is a unique identifier for the table. A foreign key is an attribute on a 
relation that contains the primary key of another relation in order to relate one table to 
another. Figure 6 is an example of a relation. 
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Figure 6. Example of a Relation 

C. DATABASE DESIGN 



The goal of the design phase is to develop a model for one or more applications 
that will support current and future operations. Database design includes the definition 
of tables, attributes, and relationships among tables. The design methodology used in this 
thesis is summarized in Figure 7. 

The schema is a formal definition of the logical records that make up the database 
and the ways that relationships among records are represented. Logical database design 
transforms the formal representation of entities and their relationships, called a conceptual 
schema, into a processable schema for a given system application. The logical data 
structure (LDS) is a graphical depiction of the four components: entity, attribute, 
identifier, and relationship. The identifier describes the entity, attribute, or relationship 
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Figure 7. Database Design Process 

(e.g., LOCN identifies an attribute in Figure 6). A collection of LDSs describing the 
conceptual information structure is determined by the user. For the DASC application, 
the database requirements defined in the Information Flow Requirements section of 
Chapter HI require that the user be able to receive the ATO, to archive and extract 
information from it, and manipulate it into desired formats. The ability to record and file 
immediate requests, BDAs, and other DASC related information, and to query the 
database to extract statistical information is also required. Entity-Relationship modeling, 
a top down approach to data modeling, helps the designer to capture data requirements 
and transform them into a logical data stmcture and user schema. 
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1. Entity-Relationship Model 

The Entity-Relationship (E-R) approach is unique among database design 
techniques in that it can be used to design a database independent of the underlying 
database model (hierarchical, network, relational). It is based on a theoretical foundation 
of relational algebra, and aids in communication between designers and users. The E-R 
modeling steps are; 

1. classification of entities and attributes 

2. identification of generalization hierarchies 

3. determination of the relationships among the entities 

4. definition of the mapping cardinality between each relationship and entity. 

(Teorey, 1990, p. 55) 

The E-R model uses entities to represent a real world thing, object, or concept 
(e.g., ATO). Entities contain descriptive information called attributes (e.g., ATO contains 
Start Time, and Stop Time). Attributes that may be repeated in an entity are called 
multivalued attributes, and will be classified as separate entities (e.g., ATO has a repeating 
ATO Mission field, wUl be decomposed into a separate ATO Mission entity). Attributes 
should be attached to the entity they best describe. An entity can usually be described 
by a noun. If one entity is dependent on the existence of another entity (e.g.. Mission 
Data is dependent upon ATO), then that entity is described as a weak entity. A gerund 
is a relationship converted to an entity (e.g., customer ships a product, but the shipping 
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is done by clerks). If entities relate to themselves person-mzxnQd-person), then the 
relationship is called recursive. 

A relationship is an association between two or more entities. Relationships 
are usually described by verbs in the E-R diagram (e.g., ATO contains Mission Data). 
The degree of a relationship is the number of entities associated with the relationship. 
A relationship with n associated entities is called n-ary (e.g., unary (1), binary (2), and 
ternary (3)). An entity is a ternary relationship if an instance of an entity can be 
associated with one instance of each of two associated entities. An example is the three 
entities Mission, JTAR, and Unit associated by the relationship "requests" . 

Values associated with the connectivity between entities are "one" or "many". 
The number associated with the term "many" is called the cardinality of the connectivity. 
Functional dependency refers to the relationship between attributes. If, when given a 
value of attribute x, one can determine the value of attribute y, then y is said to be 
functionally dependent on x. When two attributes functionally determine each other, a 
1; 1 relationship occurs (e.g.. Control Agency determines Callsign, and Callsign determines 
Control Agency). If one attribute functionally determines another but not the reverse, a 
1:M relationship occurs (e.g.. Callsign determines Mission Number, but Mission Number 
does not determine Callsign). Finally, if neither attribute is functionally dependent on the 
other, a M;M relationship occurs (e.g.. Mission Number and Request Number do not 
determine each other). (Kroenke, 1987, p. 163) 

Participation rules may also pertain between entities. Obligatory participation 
requires that every instance of an entity must participate in a relationship (e.g., all BDAs 
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must be assigned to a Target). Non-obligatory participation is an instance of an entity 
mot needed to participate in a relationship (i.e. a BDA may exist with no JTARs). A 
generalization/specialization {ISA) occurs in a relationship when an entity is partitioned 
by different instances of a common attribute. An example is the entities Mission Location 
and Target Location which share the common attribute Location, but have distinct 
attributes associated only with that generalization/sp>ecialization (e.g., Mission Location 
has the attribute Location Type, while Target Location has the attribute Target Type). In 
the example above, ATO Mission can contain either a Target Location or a Mission 
Location. 

When translating the E-R model to the relational approach, each entity 
becomes a table, each attribute becomes a column in the table, the unique identifier 
becomes the primary key, and that primary key becomes a foreign key on the many side 
of 1:M relationships. 

2. Normalization 

Relations are often defined in a form that suffers from problems in terms of 
integrity and maintainability. Updates to a database may result in the elimination of 
useful data as an unwanted side effect. Also, when the data is defined as a single large 
table, updates can result in large amounts of redvmdant data. Classes of relational 
database forms, called normal forms, are defined to avoid these problems and maintain 
high integrity and maintainability. The process of creating the appropriate normal forms 
is called normalization. (Teorey, 1990, p. 91) 
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Normalization is a process of assigning attributes to the appropriate entities. 
It is a bottom up approach to data modeling. The principles of normalization dictate that 
data items belong together in a logical group, and these groups can be identified by their 
own unique identifier or key. The data in each group should describe one, and only one 
thing. Normalization for the relational model usually requires normalizing relations to 
Boyce-Codd Form, or the equivalent as defined below. 

Recalling the definitions of a relational data model, aU relations are said to be 
in first normal form (INF) if they have non-repeating groups within a tuple. Consider 
the relation: 

ROUTE (Point Number . Location) 

where Location represents the location of a point. This is a repeating group for multiple 
missions because different locations may be assigned the same point number for separate 
missions. To fix this, the relation would become: 

ROUTE (Point Number . Mission Number . Location) 
where each location would have a separate tuple. 

A relation is in second normal form (2NF) if it is in INF and aU non-key 
attributes are dependent on the primary key. An example would be the Route relation 
used earlier: 

ROUTE (Point Number . Mission Number . Location, Mission Type) where 
Mission Number — > Mission Type 

The non-key attribute is dependent on part of the primary key. To fix this the relation 
is decomposed into the following two relations: 
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ROUTE (Point Number . Mission Number . Location) 



MISSION (Mission Number . Mission Type) 

A relation is in third normal form (3NF) if the above exists and there is no 
non-key attribute determined by anything but the key (transitive dependency). A relation 
in violation of third normal form would be: 

ROUTE (Point Number . Mission Number . Location, Location Comments) 
where Point Number, Mission Number — > Location 
Location — > Location Comment 

This is in violation because Location, a non-key attribute determines Location Comment, 
another non-key attribute. This is fixed by decomposing the relation into two relations; 
ROUTE (Point Number . Mission Number . Location) 

LOCATION (Location, Location Comments) 

Finally, a relation is in Boyce-Codd Normal Form (BCNF) if every 
determinant is a candidate key, or no anomalies regarding functional dependencies exist. 
BCNF deals with relations with overlapping keys. An example of a relation with 
overlapping keys is: 

ROUTE (Point Number . Mission Number . Location . Point Name) 
where Point Number, Mission Number — > Point Name 
Point Number, Location — > Point Name 

These aie overlapping keys because both keys contain Point Number. To fix this 
problem, the relation is decomposed into two relations: 

ROUTE (Point Number. Mission Number. Location) 
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POINT (Point Number . Point Name) 



A decomposition is said to be lossless if it preserves the functional 
dependencies of the original relation. For example if the two decomposed relations above 
are joined, the resulting relation will be equal to the original relation. 

The bottom-up, or normalization approach in developing a logical database 
design will result in the relations being normalized to the degree required, usually, a 
collection of tables in BCNF. The resulting processable schema allows the DBMS to 
physically manage the database. 

D. SCENARIO 

To model the user defined requirements, a simple scenario will be described based 
on current operations in the DASC. The DASC wUl be treated as a "black box" i.e., 
ignoring its internal functions. Likewise, external agencies wUl be ignored. The E-R 
model is concerned only with the information requirements of the DASC, not the means 
by which information was transmitted or received, or its origin or destination. 

The scenario is as follows: 

1. The DASC receives the ATO and manipulates it for display on the 
appropriate log (FRAG). 

2. The DASC receives JTAR 26-1 and processes it, assigning a mission to 
execute it. 

3. The DASC transmits mission data to the requestor and requests launch of 
the assigned mission. 
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4. The aircraft reports to the DASC, the DASC briefs the A/C using the 9- 
Ime brief format, and turns the A/C over to the terminal controller at the 
appropriate control point. 

5. The DASC requests mission status on a rotary wmg mission. 

6. The A/C executing JTAR 26-1 checks out with the DASC, mission 
complete, with a BDA. 

7. The DASC receives a change to a preplanned mission. 

8. At the end of the day, the DASC transmits an operational summary 
(OPSUM) report. 

E. DASC DATABASE DESIGN 

Relational database application capabilities will be demonstrated by extracting 
mfonnation from the current databases used in the DASC. This involves combining the 
automated files (MTS ATO), non-automated data (immediate requests, RIO logs, BDAs, 
operational summary), and user requirements discussed in Chapter El. 

This information provides the basis for determining the entities, attributes, and 
relationships for the E-R diagram. The abbreviations and field structures of the identifiers 
duplicated the existing MTF and report formats where applicable. The following entities 
were identified to pertain to the DASC ATO application: 

- AIR TASKING ORDER - defines time period and type of ATO 

* BATTLE DAMAGE ASSESSMENT - defines mission results of a particular target 

* CONTROL AGENCY - defines characteristics of a particular control agency 

* IMMEDIATE REQUESTS - defines unit supported for an immediate air support 
request 
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• MISSION (ATO MISSION) - defines basic characteristics of the particular mission 
to include aircraft data 

• MISSION LOCATION - defines mission location 

• RECEIVING AIRCRAFT - defines mission data for aircraft requiring refueling 

• RECONNAISSANCE - defines reconnaissance data 

• RECON TARGET - defines reconnaissance target data 

- RIO LOGS - defines actual mission data 

• ROUTE - defines mission route information 

• TARGET LOCATION - defines mission target data 

The relationships defined between entities depicted in Figure 8 include: 

- ASSESSES - BDA may be reported on a TARGET LOCATION 

• COMPRISES - ATO is comprised of various MISSIONS 

• CONTROLS - MISSION is controlled by various CONTROL AGENCY(ies) 

• INTEREST IN - RECONNAISSANCE mission executes various RECON 
TARGETS 

• MAY DESIGNATE - MISSIONS may follow certain ROUTES 

• REFUELS - MISSION LOCATION may refuel RECEIVING AIRCRAFT 

• REQUESTS - IMMEDIATE REQUESTS request MISSION to perform 

• UPDATES - RIO LOGS update the ATO with actual mission data 

Mapping cardinality between each entity was specified to complete the diagram. 
Appendix D lists the cardinality mles used for each link. 

Figure 8 depicts the resulting E-R diagram using an E-R modeling tool called E-R 
Designer by Peter Chen and Associates. Appendix D lists and explains the entities, 
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Figure 8 . 



Entity-Relationship Model 
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attributes, relationships, and cardinality rules depicted on the E-R diagram. 

The entities BDA and Target Location linked by the relationship Assesses will be 
used as an example of how to read the diagram; There can be as few as zero or as many 
as N (many) BDAs assessing each Target Location-, and there can be one and only one 
Target Location assessed in each BDA. The term TSA’ refers to a generalization 
occurrence on the entity ATO Mission. ATO Mission must have one of the entities; 
Target Location, Mission Location or Reconnaissance, as a member. 

The E-R model weis then loaded into the Normalizer tool of E-R Designer to 
validate the schema. The initial schema generated by the E-R Designer tool is shown in 
Appendix E. Functional dependencies (FD) were defined in each relation. The 
normalizer tool normalized the relations to the BCNF and decomposed the relations into 
FD-preserving and lossless-join 3NF relations. It also ensured that complex relations 
were broken down into simpler ones in which related data items were grouped and 
duplication minimized. The user interaction log for defining the functional dependencies 
is listed in Appendix F. The resulting schema from the Normalizer tool is displayed in 
Appendix G. 

F. IMPLEMENTING THE DASC SCHEMA ON A RELATIONAL DBMS 

The relational schema developed in the previous section is not linked to any specific 
DBMS. No database package meets all the features and qualifications of a "fully 
relational" database; however, many relational databases exist that can use the schema 
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generated. To demonstrate the potential of a relational database, dBASE IV is used as 
a prototype implementation of the DASC application. 

A DBMS is a program, or set of programs, that processes the database. The DBMS 
allows the user to create, maintain, and access a database. The DBMS allows the 
program to be separate from the application. The application can be thought of as a 
collection of menus, forms, reports, and programs that satisfies the needs of a user or 
group of users. The DBMS is a set of programs or tools which allows developers to 
design and implement a system which users can access. (Kroenke, 1987, p. 62) The 
features and functions of a DBMS include: 

* Change the data as the real world changes 

* Support a data structure that corresponds to the real world 

- Protect the data from corruption from authorized users 

* Protect the data from unauthorized users 

* Support access to data by multiple users simultaneously 

- Recover from software and hardware failures 

* Get information out of the database easUy 

- Improve productivity of the development programmers 

- Reasonable performance 

A database was created using the normalized relational schema field format 
developed by E-R Designer. A simulated ATO was loaded into the database. Reports 
were generated linking tables to get the desired outputs. Ad hoc queries were conducted 
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to determine the application capabilities. Sample reports and queries are listed in 
Appendix H. 

Database generation creates an actual physical structure which is generated from the 
conceptual schema. The DASC application schema created by E-R Designer and listed 
in Appendix G determined: 

• database names 

* field names 

* field types 

• field length 

The data files created above were used to define the database structure in dBASE 
IV. dBASE IV uses a matin menu called the Control Center to access and store files. 
dBASE rV achieves the functions of data management (creation, interrogation, updating, 
administration) through the Control Center. For example, the relation Air Tasking Order 
was used to create the database file ATO in the Data Panel. Field names were derived 
from the attributes ATO Start, ATO Stop, and Air Tasking Code using the attribute type 
(character or numeric) and length as shown in Appendix G. 

Unless otherwise specified, dBASE IV stores records in the order in which they are 
entered. dBASE IV can be manipulated to store and retrieve data in a sorted order by 
physically rearranging the records. Another way to sort, or retrieve, data is by creating 
an index field on a field value. Indexes allow data to be retrieved "directly" rather than 
by doing a sequential search, thus indexing makes some retrievals more efficient. For 
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example, since the DASC ATO application will require information on particular mission 
numbers, the Mission Number field was indexed when delineated in a database (relation). 

Once the database structures were created, data was loaded into the appropriate 
databases. An ATO was developed consisting of seven missions. Manual insertion of 
data was done ensuring all tables contained some data. The actual DASC application wUl 
require a compiling program and parser to automatically upload MTS data to the DASC 
application. 

The next step was to create database queries and views. A query is the retrieval of 
a specific table, possibly requiring the join of two or more tables, to meet a stated 
condition. Queries may require that data be drawn from multiple tables. dBASE IV uses 
views to help with query operations. In general, a view is a virtual table which is a 
subset of one or more existing tables in the database. In dBASE IV, it’s actually stored 
physically but this is not how all DBMSs do views. For example, a mission status may 
be requested on a troop lift from the DASC. The DASC would use the DASC application 
to find this information by creating a view linking the attributes of A!C Status database 
with the A/C Weapons database. A query is made on this view listing all records whose 
AlC Type field type is "CH-46". This query would create a view of the mission data of 
mission "30H0002". These queries can be permanently stored in the Queries panel of the 
control center in dBASE FV. 

Forms files display customized screens. This can be used for entering, updating and 
displaying data on a particular form. The custom form can be created using the tools in 
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dBASE IV. An example is the Battle Damage Assessment form contained in Appendix 
H. Fonns may also be created using the special views created in the queries panel. 

Reports can be generated in dBASE IV from one or more tables using the above 
procedures. The reports can be printed or displayed on screen. Appendix H contains a 
sample Report-In/Out Log and Immediate Air Support Summary Report. 

Design and implementation of the DASC schema as described above is the 
responsibility of the Database Administrator (DBA). The DBA must ensure that the 
integrity of the underlying DASC database is maintained at all times. This entails a 
number of critical functions as described next. 



G. DATABASE ADMINISTRATION FOR THE DASC DATABASE 

Database Administration is a technical function that is responsible for physical 
database design and for dealing with technical issues such as security enforcement, 
database performance, and backup and recovery. (Hoffer, 1991, p. 339) The Database 
Administrator for the DASC database will need to be involved with the following: 

• referential integrity 

• concurrency control 

• backup and recovery 

• database security 

• handling missing data 

• training 
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1. Referential Integrity 

Referential integrity is concerned with the validity of references by one object 
in a database to some other object(s) in the database. Rows in one relation may refer to 
a row in another relation, and problems can occur when inserting/deleting data. A 
referential integrity constraint requires that for each row of one table, the "referencing 
table", the value of the foreign key value must be the same as the value of the 
corresponding primary key column in some row of the referenced table or else be null. 
A row should not be able to be inserted in the referencing table unless it exists in the 
referenced table. Additionally, a row should not be able to be deleted from the referenced 
table if there is a matching row in the referencing table. For example, if a mission is 
deleted from the AlC Status relation, then the deletion should either: 

1. be deleted in every relation which contains the same mission, 

2. be disallowed, or 

3. nullify the mission number attribute in the referencing table(s). 

Referential integrity constraints can be enforced by an application program or 
by a DBMS that includes facilities for enforcement. dBASE IV does not provide 
referential integrity facilities. 

2. Concurrency Control 

Concurrency in a database environment means that more than one user can 
access and manipulate data at the same time. Multiple users of the DASC database can 
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compromise the data unless there is concurrency control. An example would be where 
users A and B both update the relation Battle Damage Assessment. User A updates the 
field BDA Comment and saves the data, while user B updates the field Unit Supported 
and saves the data 5 seconds later. The information updated by user A would be lost. 

Controlling concurrent access may be done by locking or denying access to 
other users until the update is completed. Locks may be implemented at different levels 
(database, table, block, record, field), and may provide shared access but allow only one 
update user. DBMS products provide different locking capabilities. dBASE IV provides 
concurrency control by locking records automatically by default, or by locking table 
access through the protect and exclusive use commands in the application generator tool. 

3. Backup and Recovery 

Database recovery procedures are required to restore a database quickly after 
a loss or damage. The DBMS should have tools to recover data firom program aborts, 
software failures, and hardware failures. In program aborts, the DBMS detects 
transactions started and aborted without "commit", then effects an automatic "rollback". 
When a system "crashes" or loses power, the DBMS examines the transaction log once 
initiated and effects a "rollback" for all incomplete transactions. The database must be 
restored from a backup copy for hardware failures, and the DBMS must reproduce 
transactions on log since the backup. dBASE IV, for example, provides automatic 
"rollback" through the application generator tool. dBASE IV also has the capability to 
log terminal activities into a text file to produce and an audit trail of database 
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transactions. This audit trail, however, cannot be automatically reapplied to restore the 
database. 

4. Database Security 

Data Security protects the data from unauthorized users. The first level of 
security is physical security. The next is the use of passwords both into the system and 
into the programs. The DBA can create views for different classes of users controlling 
the type of access (read, write, delete) each user has to the data. 

5. Handling Missing Data 

Procedures must be established by the database administrator to handle missing 
infonnation. Data that is missing, lost, or incomplete in the DASC application must be 
dealt with in the design phase. 

6. Training 

The DBA interfaces with the users for training purposes, and to determine 
ongoing system requirements. DBMS software is complex and consumes resources. 
Performance is measured in time required to support a function, number of users 
supported, and number of transactions per second. There is a trade-off between 
perfonnance vs. features, performance vs. flexibility, and performance vs. portability. 
Reasonable perfonnance will depend on the balance of these trade-offs. (Hoffer, 1991, 
p. 363-384) 
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H. SUMMARY 



This chapter discussed and applied the relational theory for data modeling to the 
DASC application using the E-R approach and nomialization. An entity-relationship 
model created by the support tool E-R Designer was combined with the Normalizer 
support tool to develop a relational schema for the DASC application. The logical data 
structure was translated to a relational schema, and implemented on a microcomputer 
DBMS called dBASE IV. Although further work is needed before the DASC application 
can be fully implemented as a functional prototype, the potential for this approach and 
resulting application was demonstrated. The Database Administrator will play a key role 
in developing the DASC ATO application. A DBMS that provides interactive 
management facilities will assist the DBA in his responsibilities. 

The final chapter summarizes the study’s results, and suggests areas for future 

study. 
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V. CONCLUSIONS 



A. CONCLUSIONS 

This thesis developed a logical schema for a centralized relational database, given 
the requirement specifications for a DASC database application. The thesis illustrates the 
steps of E-R modeling, normalization, and implementation of the schema using a 
relational DBMS. Database design is an evolving activity. As user requirements expand 
and change, the conceptual schema and database structures must change accordingly. The 
methodology used in the original design is important since it may be reused to keep the 
database current as more aspects of the DASC application are developed. 

The E-R approach is particularly useful in the early stages of the database lifecycle, 
which involves requirements analysis and logical design. When requirements are 
determined from end-user interviews and modeled in terms of E-R diagrams, immediate 
feedback can be obtained concerning the veilidity of the database. Another advantage of 
the E-R approach is that the schema is independent of any particular DBMS environment 
and therefore can be used with potentially many different DBMS platforms. 

Once a logical data structure has been generated, it is a straightforward process to 
implement the schema m a specific environment as we have shown with dBASE IV. The 
relational DBMS manages ad hoc queries and new applications that would be more time 
consuming to implement with other models. 
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Relational databases are easy to design, maintain, and use. They enforce data 
independence and encourage data sharing. They readily support application development, 
prototyping, and distributed data applications. Relational architecture will support many 
applications and is recommended for adoption for implementation of the DASC 
application. 



B. FURTHER RESEARCH 

This thesis represents only an initial study into the potential of implementing a 
relational database application in the DASC. The study examined a passive DBMS where 
queries and transactions occurred only when explicitly requested by the user or 
application program. Future study is suggested in: 

* design of an active database management system aimed at meeting the needs of 
applications requiring time-constrained data management and processing. A High 
Performance Active (HIPAC) DBMS automatically monitors events, evaluates 
conditions defined over the state of the database when appropriate events occur, 
and, based on the result of conditions evaluation, invokes actions associated with 
the event-condition pair. 

• evaluation of implementing the database design in SYBASE, the Marine Corps’ 
chosen standard for relational DBMSs. 

* evaluation of the alternative file indexing structures of the DASC application. This 
system performance evaluation should determine the stmcture with the best 
performance while rninirnizing the volume of the database. 

• define the stmcture and content of a database that would support the entire Marine 
Air Command and Control System and Marine Tactical Command and Control 
System. Standardization of data elements used within the system should be 
addressed. Considerations should be given to implementing the design in a 
distributed database environment. 
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* development of an expert system for assignment of missions to immediate air 
requests that interacts with the DASC application. The expert system could be 
based upon standard operating procedures to assist decision makers in the DASC. 

• determine the communication equipment requirements to include parser and 
compiling requirements for the transmission, receipt, and storage of the ATO. This 
should include security and integrity checking in the transmission specifications. 
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APPENDIX A: GLOSSARY 



Anomaly - An undesirable consequence of a database modification. 

Application - A collection of menus, reports, forms, and programs that addresses the 
needs of the users. 

Attribute - A data element that describes an entity. A column of field in a relation. 

Candidate Key - An attribute or attribute group that could be used as a key in a relation. 

Command and Control Facility (C2FAC) - An organization element that needs to 
communicate with another to perform its tasks. 

Command and Control (C2) System - The facilities, equipment, communications, 
procedures, and personnel essential to a commander for planning, directing, and 
controlling operations of assigned forces pursuant to the missions assigned. 

Data - A fact or condition represented in a form that is usable by an Automated Data 
System including its operators. 

Data Item - The smallest unit of named data that has meaning in the real world. 

Data Dictionary - A user-accessible catalog of data about a database. 

Data Element - Used synonymously with data item. 

Data Field Identifier (DFI) - The DFI provides the identification for the class of data 
relating to a message field in the MTS message standard. The DFI contains a unique 
number, name, and definition. The DFI is a generic definition of the concept represented 
by all associated DUIs. All DFIs most have at least one associated DUI. 

Data Model - A language describing the structure and processing of a database. 

Data Use Identifier (DUI) - The DUI further identifies the functional or categorical 
context in which the DFI is used. The DUI contains a unique name among all DUIs and 
a unique number among the DUIs within the DFI. All DUIs have at least one Data Item 
(DI) or field or attribute. 
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Database - An organized and integrated collection of stored operational data used by an 
Automated Data System. 

Database Administrator - The person or group responsible for the design, creation, 
maintenance, and control of the database. 

Database Management System - A software function providing data handling services 
to operators (end users), application programmers, and Database Administrators. 

Entity - A real world object that is important to the system application. 

Entity Instance - An occurrence of an entity. 

Entity-Relationship Diagram - A diagram used in database design that illustrates entities 
and the associations among them. 

File - The collection of records of a single type. 

Foreign Key - An attribute that has a key of a different relation. 

Functional Dependency - Relationship between X and Y such that, given a value of X, 
one can determine the value of Y. Written as X -> Y. 

Hierarchical Data Model - A data model that such that each record has exactly one 
parent, except the root, which has no parent. 

Identifier - The attribute(s) and/or relationship(s) that uniquely identify a particular entity. 

Interoperability - The ability of systems, units, or forces to provide services to, and 
accept services from other systems, units, or forces, and to use the services exchanged to 
enable them to operate effectively together. 

Intraoperability - Interoperability among the Marine Corps systems. 

Key - A group of one or more attributes that uniquely identifies a row (tuple, record) 

Local Area Network - A collection of geographically close microcomputers that 
communicate. 

Meta-data - Data about the stmcture of a database that is stored in the data dictionary. 

Network Data Model - A data model in which all relationships are one-to-many and a 
chUd can have multiple parents as long as they are different record types. 
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Primary Key - An attribute or attribute group chosen as the key of a relation. 

Protocol - Communication protocols are processes or sets of mles controlling the 
interchange of information. 

Record - A group of related data items treated as a unit. 

Record Type - Defines the structure of a record by identifying the names of the data 
elements present. 

Record Occurrence - One particular instance of a record type with values assigned to 
the data elements. 

Relation - A two-dimensional table containing single valued entries and no duplicate 
rows. 

Relational Database - A database stmctured in accordance with the relational data model. 

Relational Data Model - A data model in which data is stored in tables, and association 
between tables are represented within the table data. 

Relationship - An association between two entities. 

Schema - A logical view of a database. 

Transitive Dependency - A relationship between attributes X, Y, and Z such that, if Y 
is detennined by X, and Z is determined by Y, then Z is determine by X. Written as if 
X -> Y and Y -> Z, then X -> Z. 

Tuple - A row or record in a relation. 
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APPENDIX B: MILITARY ACRONYMS 



AAW - Antiair Warfare 

ACCS - Army Command and Control System 

ACE - Aviation Combat Element 

ASOC - Air Support Operations Center 

ASR - Assault Support Request 

ASRT - Air Support Radar Team 

ATO - Air Tasking Order 

BDA - Bomb Damage Assessment 

CAS - Close Air Support 

COC - Combat Operations Center 

CP - Conunand Post or Control Point 

CRLCMP - Computer Resources Life Cycle Management Plan 

C2 - Command and Control 

C2FAC - Command and Control Facility 

C3I - Command, Control, Communication and Intelligence 

DASC - Direct Air Support Center 

DCT - Digital Communications Terminal 

DEI - Data Field Identifier 

DI - Data Item 

DUI - Data Use Identifier 

EMP - Electro-magnetic Pulse 
EW/C - Early Waming/Control 

FAC - Forward Air Controller 

FAC(A) - Forward Air Controller (Airborne) 

FMFM - Fleet Marine Field Manual 
FRAGO - Fragmentation Operation Order 
FSCC - Fire Support Coordination Center 
FBC - Future Battle Cell 

GCE - Ground Combat Element 

HC(A) - Helicopter Coordinator (Airborne) 
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IDASC - Improved DASC (Facility) 

ISEA - In-service Engineering Agent 

JTAR - Joint Tactical Air Request 

LAAD - Low Altitude Air Defense 
LAAM - Light Antiaircraft Missile 

MACCS - Maine Air Command and Control System 

MACG - Marine Air Control Group 

MAGTF - Marine Air-Ground Task Force 

MATCS - Marine Air Traffic Control Squadron 

MCASS - MTACCS Common Application Support Software 

MCHS - MTACCS Common Hardware Suite 

MCTSSA - Marine Corps Tactical System Support Activity 

MMI - Man-machine Interface 

MTACCS - Marine Corps Tactical Command and Control System 
MTF - Message Text Format (also USMTF) 

MTS - Marine Tactical Systems 

NAVELEXCEN - Naval Electronics Systems Engineering Center 

NDI - Non-developmental Item 

NTACS - Naval Tactical Air Control System 

ORD - Operational Requirements Document 

PLRS - Position, Location, and Reporting System 
P31 - Pre-planned Product Improvement 

RAC - Refueling Area Coordinator 
RIO - Report in/out 
ROC - Required Operational Capability 
RPV - Remotely Piloted Vehicle 

SAAWC - Sector Antiair Warfare Coordinator 
SAD - Senior Air Director 

TAC - Tactical Air Commander 

TAC(A) - Tactical Air Coordinator (Airborne) 

TACC - Tactical Air Command Center (USMC) 

TACP - Tactical Air Control Party 

TACS - Tactical Air Control System (US Air Force) 
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TAOC - Tactical Air Operations Center 
TAR - Tactical Air Request 
TCO - Tactical Combat Operations 
TDS - Tactical Data Systems 
TIOP - Tactical Interface Design Plan 

USMC - United States Marine Corps 
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APPENDIX C: DASC INFORMATION REQUIREMENTS 
This appendix exhibits current DASC information requirements pertaining to the 
ATO database application. The messages, forms, and reports included are: 

• the message text format Air Tasking Order 

* the Joint Tactical Airstrike Request 

• the Report-In/Out Log 

* the Operational Summary Report 
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AIR TASKING ORDER 



1. General 

The Air Tasking Order/Confirmation message is computer readable and includes 
information based on the users needs. The message can include the following groups of 
information. If the group (set) is used the format is as follows: 

SET NAME/FIELD 1/FlELD 2/.../FIELD N// 

* Mandantory sets and fields are underlined. A field is mandandory only if that set 
is mandantory. 

* Vetical lines with arrows show repeatable sets and nested segments. 

* Capital letters means enter as is. 

2. Message Map 



EXER /exercise name/ additional identifier// 

OPER /operation name/ plan orginator and number/option name/second option name// 

MSID/ATOCONF/orginator/ message serial number/month/qualifier/quailfier serial 
number// 

REF /serial letter/Cusmtf message short title) or (type of reference )/orginator/date- 
time group/ (msg ser number) or (doc ser number)/special notation/(sic) or (filing 
number)// 

AMPN/free text to explain preceeding reference set// 

NARR/free text to explain preceeding reference set// 

CANX /serial letter/(usmtf message short title) or (type of reference )/orginator/date- 
time groupA msg ser number) or (doc ser number )/special notation/(sic) or (filing 
number)// 

PERID/time from/TO: time to/ ASOF: as of time// 

AJRTASK/air tasking/ air tasking comments// 

TASKUNTT/tasked unit designator/ ICAO location/comments// 
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MSNDATA/mission number/package identification/aircraft call sign/number and 
type of aircraft/mission type/alert status/primary configuration code/secondary 
configuration code/iff-sif code and mode/ / 

MSNLOC /mission start day-time/mission stop day-time/ mission location 
name/(altitude) or (flight leyel)/air support request number/area coordinates// 

TGTLOC /day-time on target/day-time off target/target identifier/target type/ desired 
mean point of impact/air support request number/tzirget comments// 

RECDATA /request number/mission priority/day-time on tzurget/latest time 
information of yalue/reconnaissance mission type/cpyerage type/imagery 
type/imagery code/coyerage:mode/TGTCOD: reconnaissance target code/ print 
scale/deliyery address// 

TRCPLOT/ location of initial point/ trace point location// 

CONTROL /type of control/callsign/(primary frequency) or (primary frequency 
designator)/ ! secondary frequency) or secondary frquency designator)/report-in 
point/control comments// 

FACINFO/ callsign/(primary frequency) or (primary frequency 
designator)/ ! secondary frequency) or secondary frquency designator)/report-in 
point/support unit identity/control comments// 

ELECMBT /aircraft callsign/priority/mission location/ (altitude) or (flight leyel)/time 
on station/time off station/primary (frequency) or frequency designator/secondary 
(frequency) or frequency designator// 

REFUEL /tanker call sign/tanker mission number/air refueling control point/(altitude) 
or (flight leyel)/air refueling control time/total offload of fuel/primary (frequency) 
or frequency designator/ secondary (frequency) or frequency designator// 

VREFUEL /mission number/aircraft call sign/number and type aircraft/total offload 
of fuel/air refueling control time/ tanker assignment/refueling fuel type/recieyer 
comments/ 

AKNLDG /acknowledgement instructions/ / 

DECL /downgrading instructions/ / 
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JOINT TACTICAL AIRSTRIKE REQUEST 



JOINT TACTICAL AIRSTRIKE REQUEST 
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& DESIRED ORO/RESULTS 
0 ORDNANCE 



. 0 DESTROY^ 



. 0 neutrauze. 



. 0 HARaSS/INTEKDICT. 



7 FINAL CONTROL 
0FAC/RABFAC , 
0 ASRT 



0 CALL SIGN 
0 -FREO 



0 FREO 

0 FIX/CONT PT 



. REMARKS 

0IP 

0HDG 

0 DIST 

0 MARK TYPE _ 
0 FRIENDLIES 
0 EGRESS 



. CODE . 



0 BCN TO TGT BRnG/BCN COORD _ 
0 BCN TO TGT RANGE/TGT C00RD_ 
0 BCN ELEVATION 



. FT MSL 





ACKNOWLEDGED 




BDE/REGT 




DIVISION 




OTHER 



section II -coordination 



9. NGF 



10. ARTY 



11 AiOiC2;G-3 



12. REQUEST 

0 APPROVED 
Q DISAPPROVED 



14. REASON FOR DISAPPROVAL 



15 RESTRICTIVE FIRE/AIR PLAN 

0 IS NOT 0 number 



IB IS IN EFFECT 

0 (FROM TIME) 



0 (TO TIME) 



17. LOCATION 

IS- 



1B WIDTH 
(METERS) 



(FROM COORDINATES) 



(TO COORDINATES! 



19 ALTITUDETVERTEX 

Q D 

(MAXIMUM/VERTEX) 



(MINIMUM! 



SECTION III -MISSION DATA 



20 MISSION NUMBER 



21. CALL SIGN 



22. NO & TYPE AIRCRAFT 



23. ORDNANCE 



24 est/act takeoff 



25 EST TOT 



28. CONT PT/RDNVS 
(COORD/NAVAlD FIX) 



27 INITIAL CONTACT 



28 FAOASRT/TAQA) CALL 
SIGN FREO 



29 RESTRICTIVE FIRE/AIR 
PLAN SEE 15-19 



30. TGT DESCRIPTION 



31 -TGT COORD/ELEV 



32. BATTLE DAMAGE ASSESSMENT (BDA REPORT) 

0 TGT COORD 

0 TIME ON/OFF . 



0 V.ORD ON TGU*/. TGT DESTROYED . 

0 RESULTS 

0 UNIT SUPPORTED 



* TRANSMIT AS APPROPRIATE 



acknowledged 



TUOC 



aSRT 
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REPORT-IN/OUT LOGS 



REMARKS 
































a 
































CONTROL 
































§ 
































ETR 
































ATA 
































ETA 
































MISSION 
































ORD 
































NO TYPE 
































7T, 

2 

to 

i . 
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REPORTS 

DIRECT AIR SUPPORT CENTER 
OPERATIONAL SUMMARY 



DATE: 



FIXED WING 



DAILY MONTHLY TOTAL 



NUMBER MISSIONS SCHEDULED 








NUMBER UNSCHEDULED MISSIONS FLOWN 








NUMBER OF MISSIONS CANX 








TOTAL NUMBER MISSIONS FLOWN 








TOTAL NUMBER OF A/C FLOWN 








NUMBER MISSIONS RIO' ED IN 


P 


c 


T 


C 


P 


T 


C 


P 




NUMBER OF MISSIONS RIO' ED OUT 





















R£MAP.KS : 



HELO 



DAILY MONTHLY TOTAL 



NUMBER MISSIONS SCHEDULED 








NUMBER UNSCHEDULED MISSIONS FLOWN 








NUMBER OF MISSIONS CANX 






— 


TOTAL NUMBER MISSIONS FLOWN 






TOTAL NUMBER OF A/C FLOWN 








NUMBER MISSIONS RIO' ED IN 


P 


C 


T 


C 


P 


T 


C 


P 




NUMBER OF MISSIONS RIO' ED OUT 





















REMSRKST 
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OPSOM (cont) 



MED E VAC 


DAILY 


MONTHLY 


TOTAL 1 


RC 

VD 


CA 

NX 


CO 

MP 


RC 

VD 


CA 

NX 


CO 

MP 


RC 

VD 


CA 

NX 


1 

C 

0 ; 
M > 
p 


ACTUAL 




















SIMULATED 





















KEHSF.KST 



JTAR 


DAILY 


MONTHLY 


TOTAL 


RC 

VD 


CA 

NX 


CO 

MP 


RC 

VD 


CA 

NX 


CO 

MP 


RC 

VD 


CA 

NX 


C 

0 

M 

P 


ACTUAL 




















SIMULATED 





















REt'^'tCK'ST 



ASR 

I 

f 


DAI 


LY 


MONTHLY 


TOTAL 


RC 

VD 


CA 

NX 


CO 

MP 


RC 

VD 


CA 

NX 


CO 

MP 


RC 

VD 


CA 

NX 


C 

0 

M 

P 


ACTUAL 




















SIMULATED 





















kEMAkkS : 





DAILY 


MONTHLY 


TOTAL 


TOTAL OPERATIONAL HOURS 









remarks : 
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APPENDIX D: ENTITY-RELATIONSHIP SPECIFICATIONS 



This appendix lists and explains the infoimation depicted on the Entity-Relationship 
diagram, Figure 8. It includes: 

• attribute names, abbreviations, formats, and keys 

• entities and relationship attribute listing 

• cardinality connections and rules 
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ENTITY-RELATIONSHIF ATTRIBUTES 



Attribute Name 
A/C_CALLSIGN 
Conun: A/C callsign 



Abbreviation 

C/S 



Format 



C, 12 



Key Abbrev 



ACTUAL_TIME_OF_ARRIVAL ATA N, 4 

Comm: Actual time A/C reported in with DASC 

ACTUAL_TIME_OF_RETURN ATR N, 4 

Comm: Actual time A/C reported out with DASC 



AIRCRAFT TYPE 



TYPE 



C, 6 



Y 

Y 



N 



N 



N 

N 



ATO_MSN 

REFULEE 



RIO LOGS 



RIO LOGS 



ATO_MSN 

REFULEE 



Comm: Aircraft /helicopter type/model/category (entry list 513) 



AIR_TASKING_CODE 


ATO_CODE 


C, 43 


Y 


ATO 


Comin: Code for air 


tasTcing type (entry 


list 2005) 






ALERT STATUS 


ALR 


C, 3 


N 


ATO_MSN 


Comm: Alert status 


code (Annex 33 CH 3/USMTF) 






ALTITUDE 


ALT 


C,5 


N 


MSNLOC 


Comm: A/C altitude 


(Annex 2 CH 3/USMTF) 








AMOUNT OF FUEL 


LBSFUEL 


N, 4 


N 


REFULEE 


Comm: Amount of fuel allowed per aircraft in hundreds 


of lbs 


ARRIVAL_TIME 


ATIME 


C,7 


N 


ROUTE 


Comm: Arrival time 


(Annex 2 CH 3/USMTF) 








ATO START 


ATO START 


C,7 


Y 


ATO 


Comm: Day, hour, minute, time zone of ATO Start 






ATO STOP 


ATO STOP 


C,7 


Y 


ATO 


Comm: Day, hour, minute, time zone of ATO stop 






BDA COMMENT 


BDACMNT 


C,30 


N 


BDA 


Comm: Description 


of results 








CALLSIGN 


CALLSIGN 


C, 15 


Y 


CONTROL 



Comm: Control agency's callsign 
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CONTROL AGENCY 


CONT 


C,4 


N 


CONTROL 


Comm: Code for the 


control agency type 


from the event ! 


List 


CONTROL_POINT 


RIO CP 


C,20 


N 


CONTROL 


Comm: Location the 


A/C is to check in with the control 


agency 


CONTROL POINT TYPE 


CPTYP 


C, 3 


N 


ROUTE 


Comm: Code for the 


route point type (Annex 2 


CH 3/USMTF) 


COVERAGE TYPE 


COVERAGE 


C,7 


N 


RECDATA 


Comm: Code for type of coverage (Annex 


34 CH 


3/USMTF) 




EST TIME AIRBORNE 


ETA 


N, 4 


N 


A/C_STATUS 


Comm: Estimated time A/C airborne 








EST TIME OF RETURN 


ETR 


N, 4 


N 


A/C_STATUS 


Comm: Estime time A/C returns 








FUEL_REQUIREMENTS 


FUREQ 


N, 4 


N 


REFULEE 


Comm: Total amount 


of fuel req for the 


msn in 


hundreds 


of lbs 


IFF/SIF_CODES 


IFFCODE 


C, 5 


N 


ATOJMSN 


Comm: IFF/SIF mode 


and code (lx (mode ) , 


2-4N 


(code) ) 




IMMEDIATE AIR REQUEST NUMBER IMMEDIATE 


C, 5 


Y 


IMED AIR 


Comm: JTAR, ASR, MEDEVAC Request Number 






LATEST TIME INFO OF VALUE LTIOV 


C, 11 


N 


RECDATA 


Comm: Latest time 


in year, month, day. 


hour. 


min, time 


zone 


LOCATION 


LOCN 


C, 20 


Y 


BDA 








N 


MSNLOC 








Y 


RECTGT 








N 


ROUTE 








N 


TGTLOC 


Comm: Mission location (entry list 11) 








LOCATION TYPE 


LOCTYP 


C, 6 


N 


MSNLOC 


Comm: Code for a mission location (Annex 2 CH 


3/USMTF) 




MISSION COMMENT 


MSNCMNT 


C, 22 


N 


MSNLOC 


Comm: Comments on 


the mission location 








MISSION NUMBER 


MSNNO 


C, 8 


Y 


ATO MSN 








Y 


REFULEE 








Y 


RIO LOGS 


Comm: Mission No. 


(date, fixed/helo, sequence 


(25H-0009) ) 


MISSION_START 


MS TART 


C,7 


N 


RECDATA 



Comm: Time on target 
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MISSION_TYPE 


MSN 


C,5 


N 


ATO MSN 








N 


RECDATA 


Comm: Mission type 


(entry list 107A) 








NUMBER_OF_AI RCRAF T 


NO 


C, 3 


N 


REFULEE 








N 


ATO_MSN 


Comm: Number of aircraft 








PERCENT_ORDNANCE_ON 


TARGET ORD ON TGT N, 2 


N 


BDA 


Comm: Percentage of 


Ordnance hitting 


target 






PERCENT TARGET DESTROYED TGT DESTROYED N, 2 


N 


BDA 


Comin: Percentage of 


target destroyed 








POINT NUMBER 


PN 


N, 2 


Y 


ROUTE 


Comm: Numeric sequence given to the reference point (1 


-99) 


PRIMARY CONFIGURATION_CODE PRICONFIG 


C,5 


N 


ATO MSN 


Comm: Primary configuration code for 


the aircraft 




PRIMARY_FREQUENCY 


PRIFREQ 


C, 8 


N 


CONTROL 


Comm: Frequency in 


megahertz;- or the 


frequency 


designator (blue) 


PRIORITY 


PR 


C,1 


N 


RECDATA 


Comm: Priority for 


the mission 








REFUELING TIME 


RFLTIME 


C,7 


N 


REFULEE 


Comm: Refueling time in day^^ hour^ minute;^ time 


zone 




REQUEST_NUMBER 


REQNO 


C, 6 


Y 


MSNLOC 








Y 


RECDATA 



Comm: Preplanned Air Support Request Number 

SECONDARY_CONFIGURATION_CODE SECCONFIG C,5 N ATO_MSN 

Comm: Secondary configuration code for the aircraft 



SECONDARY_FREQUENCY SECFRQ C, 8 N CONTROL 

Comm: Frequency in megahertz, or by frequency designator (blue) 



TARGET 


COMMENTS 


TGTCMNT 


C, 35 


N 


TGTLOC 


Comm: 


Comments describing the target 








TARGET 


_IDENTIFIER 


TGTID 


C, 20 


Y 


TGTLOC 


Comm: 


Assigned Target 


Number or Name 


(entry list 


11. 


table Ii; 


TARGET 


LENGTH 


TLGTH 


C,7 


N 


RECTGT 


Comm : 


Estimated target 


length (Annex 


2 CH 3/USMTF) 




TARGET 


_TYPE 


TGTTYP 


C, 6 


N 


TGTLOC 



Comm: Target type (entry list 20) 
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TARGET WIDTH 


TWDRAD 


C,7 


N 


RECTGT 


Comm: Estimated width 


or radius 


(Annex 2 CH 3/USMTF) 




TIME-OFF-TARGET 


TFT 


C,7 


Y 


BDA 


Comm: Time off target 


(day, hour 


, minute, time 


zone) 




TIME-OFF-TARGET 


TFT 


C,7 


N 


TGTLOC 


Comm: Time off target 


(day, hour 


, minute, time 


zone) 




TIME -ON- TARGET 


TOT 


C,7 


y 


BDA 








N 


TGTLOC 


Comm: Time on target 


(day, hour. 


minute, time 


zone) 




UN I T_S UP PORTED 


SUPPORTED C, 9 


N 


IMED AIR 








N 


BDA 



Comm: Unit supported by Immediate Air Request 
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ENTiry AND RELATIONSHIP REPORT 



AIR_TASKING_ORDER Relation Type - Entity 

List of Attributes (fields): 

Name Abbreviation Format 

1. ATO^START ATO.START C,7 

Day, hour, minute, time zone of ATO Start 

2. ATO^STOP ATO^STOP C,7 

Day, hour, minute, time zone of ATO stop 

3. AIR_TASKING_CODE ATO.CODE C,43 



Code for air tasking type (entry list 2005) 



ASSESSES Relation Type - Relationship 

Remark: BDAs may be reported on a target 
List of Attributes (fields): NONE 



BATTLE_DAMAGE_ASSESSMENT Relation Type - Entity 



List of Attributes (fields): 

Name Abbreviation Format 

1. LOCATION LOCN C,20 

Mission location (entry list 1 1 ) 

2. TIME-ON-TARGET TOT C,7 

Time on target (day, hour, minute, time zone) 

3. TIME-OFF-TARGET TFT C,7 

Time off target (day, hour, minute, time zone) 

4. PERCENT_ORDNANCE_ON_^TARGET ORD_ON_TGT N,2 

Percentage of Ordnance hitting target 

5. PERCENT_TARGET_DESTROYED TGT^DESTROYED N,2 

Percentage of target destroyed 

6. BDA_COMMENT BDACMNT C,30 

Description of results 

7. UNTT^SUPPORTED SUPPORTED C,9 



COMPRISES Relation Type - Relationship 

Remark: ATO is comprised of various missions 
List of Attributes (fields): NONE 

CONTROLS Relation Type - Relationship 

Remark: A/C Mission is controlled by various controlling agencies 
List of Attributes (fields): NONE 



Key 

Y 

Y 

Y 



Key 

Y 

Y 

Y 
N 
N 
N 
N 
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CONTROL_ AGENCY Relation Type - Entity 

List of Attributes (fields): 



Name 


Abbreviation 


Format 


Key 


1. CALLSIGN 


CALLSIGN 


C,15 


Y 


Control agency’s callsign 








2. CONTROL_AGENCY 


CONT 


C,4 


N 


Code for the control agency type from the event list 






3. PR1MARY_FREQUENCY 


PRIFREQ 


C,8 


N 


Frequency in megahertz, or the frequency designator (blue) 






4. SECONDARY^FREQUENCY 


SECFRQ 


C,8 


N 


Frequency in megahertz, or by frequency designator (blue) 






5. CONTROL_POINT 


RIO_CP 


C,20 


N 



Location the A/C is to check in with the control agency 



IMMEDIATE_REQUESTS Relation Type - Entity 

List of Attributes (fields): 

Name Abbreviation Format Key 

1. IMMEDIATE AIR REQUEST NUMBER IMMEDIATE C,5 Y 

JTAR, ASR, MEDEVAC Request Number 

2. UNIT_SUPPORTED SUPPORTED C,9 N 

Unit supported by Immediate Air Request 

INTEREST JN Relation Type - Relationship 

Remark: Recon MSN interested in Recon Target Data 
List of Attributes (fields): NONE 



MAY_DESIGNATE Relation Type - Relationship 

Remark: Entity Route if the Mission is to follow a certain route 
List of Attributes (fields): NONE 
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MISSION (ATO MISSION) 

List of Attributes (fields): 

Name Abbreviation 

1. MISSION_NUMBER MSNNO 

Mission No. (date, fixed/helo, sequence (25H-0009)) 

2. A/CCALLSIGN C/S 

A/C callsign 

3. NUMBER_OF_AIRCRAFT NO 

Number of Aircraft 

4. AIRCRAFT.TYPE TYPE 

Aircraft/helicopter type/model/category (entry list 513) 

5. MISSION.TYPE MSN 

Mission type (entry list 107 A) 

6. ALERT_STATUS ALR 



Alert status code (Annex 33 CH 3/USMTF) 

7. PRIMARY_CONHGURATION_CODE PRICONHG 

Primary configuration code for the aircraft 

8. SECONDARY_CONHGURATION_CODE SECCONHG 

Secondary configuration code for the aircraft 

9. IFF/SIF_CODES IFFCODE 

IFF/SIF mode and code (lx (mode), 2-4N (code)) 

10. EST_TIME_AIRBORNE ETA 

Estimated time A/C airborne 

1 1 . EST^TIME^OF^RETURN ETR 

Estimated time A/C returns 



Relation Type 


- Entity 


Format 

C,8 


Key 

Y 


C42 


Y 


C,2 


N 


C,6 


N 


C,5 


N 


C,3 


N 


C,5 


N 


C,5 


N 


C,5 


N 


N,4 


N 


N,4 


N 



MISSI0N_L0CAT10N Relation Type- Entity 



List of Attributes (fields): 

Name Abbreviation Format 

1. REQUEST_NUMBER REQNO C,6 

Preplanned Air Support Request Number 

2. LOCATION^TYPE LOCTYP C,6 

Code for a mission location (Annex 2 CH 3/USMTF) 

3. LOCATION LOCN C,20 

Mission location (entry list 11) 

4. ALTITUDE ALT C,5 

A/C altitude (Annex 2 CH 3/USMTF) 

5. MISSION^COMMENT MSNCMNT C,22 

Comments on the mission location 



Key 

Y 

N 

N 

N 

N 



79 



RECEIVING_AIRCRAFT Relation Type - Entity 

List of Attributes (fields): 





Name 


Abbreviation 


Format 


Key 


1. 


MISSION_NUMBER 


MSNNO 


C,8 


Y 




Mission No. (date, fixed/helo, sequence (25H-0009)) 






2. 


A/CCALLSIGN 


C/S 


C42 


Y 




A/C callsign 








3. 


NUMBER_OF_AIRCRAFT 


NO 


C,3 


N 




Number of aircraft 








4. 


AJRCRAFT.TYPE 


TYPE 


C,6 


N 




Aircraft/helicopter type/model/category (entry list 513) 






5. 


AMOUNT_OF_FUEL 


LBSFUEL 


N,4 


N 




Amount of fhel allowed per aircraft in hundreds of lbs 






6 . 


FUEL_REQUIREMENTS 


FUREQ N,4 


N 






Total amount of fuel req 


for the msn in hundreds of lbs 






7. 


REFUEL1NG_TIME 


RFLTIME C,7 


N 






Refueling time in day, hour, minute, time zone 







RECONNAISSANCE 
List of Attributes (fields); 


Relation Type 


- Entity 






Name 


Abbreviation 


Format 


Key 


1. 


REQUEST_NUMBER 

Preplanned Air Support Request 


REQNO 

Number 


C.6 


Y 


2. 


PRIORITY 

Priority for the mission 


PR 


C,1 


N 


3. 


MISSION^START 
Time on target 


MSTART 


C,7 


N 


4. 


LATEST_TIME_INFO_OF_VALUE 
Latest time in year, month, day. 


LTIOV 

hour, min, time zone 


C,ll 


N 


5. 


MISSION^TYPE 

Mission type (entry list 107 A) 


MSN 


C,5 


N 


6. 


COVERAGE_TYPE 


COVERAGE 


C,7 


N 




Code for type of coverage (Annex 34 CH 3/USMTF) 







RECON_TARGET 
List of Attributes (fields): 


Relation Type - Entity 




Name 


Abbreviation 


Format 


Key 


1. LOCATION 


LOCN 


C^O 


Y 



Mission location (entry list 11) 

2. TARGET_LENGTH TLGTH C,7 N 

Estimated target length (Annex 2 CH 3AJSMTF) 

3. TARGET_WIDTH TWDRAD C,7 N 

Estimated width or radius (Annex 2 CH 3/USMTF) 



REFUELS Relation Type - Relationship 

Remark: Refueling Mission Refuels Receiving Aircraft 
List of Attributes (fields): NONE 



80 



REQUESTS Relation Type - Relationship 

Remark: Immediate air support requests Mission from ATO to perform List of Attributes (fields): 

NONE 



RIO_LOGS Relation Type - Entity 

List of Attributes (fields): 

Name Abbreviation Format Key 

1. MISSION^NUMBER MSNNO C,8 Y 

Mission No. (date, fixed/helo, sequence (25H-0009)) 

2. ACTUAL_TIME_OF_ARRIVAL ATA N,4 N 

Actual time A/C reported in with DASC 

3. A(nrJAL_TIME^OF_RETURN ATR N,4 N 

Actual time A/C reported out with DASC 



ROUTE Relation Type - Entity 

List of Attributes (fields): 

Name Abbreviation Format Key 

1. POINT.NUMBER PN N,2 Y 

Numeric sequence given to the reference point (1-99) 

2. CONTROL.POINT^TYPE CPTYP C,3 N 

Code for the route point type (Annex 2 CH 3/USMTF) 

3. LOCATION LOCN C,20 N 

Mission location (entry list 11) 

4. ARRIVAL.TIME ATIME C,7 N 

Arrival time (Annex 2 CH 3/USMTF) 



Relation Type - Entity 



TARGET^^LOCATION 
List of Attributes (fields): 

Name 

1. TARGET JDENTIFIER 

Assigned Target Number or Nan 

2. TIME-ON-TARGET 

Time on target (day, hour, minut 

3. TIME-OFF-TARGET 

Time off target (day, hour, minu 

4. TARGET^TYPE 

Target type (entry list 20) 

5. LOCATION 

Mission location (entry list II) 

6. TARGET_COMMENTS 

Comments describing the target 



UPDATES 

Remark: TAD/HD logs append/update ATO with actual data List 
List of Attributes (fields): NONE 



Abbreviation 


Format Key 




TGTID 


C,20 


Y 


1 (entry list 11, table 11) 
TOT 


C.7 


N 


, time zone) 
TFT 


C.7 


N 


, time zone) 
TGTTYP 


C,6 


N 


LOCN 


C,20 


N 


TGTCMNT 


C,35 


N 


Relation Type - 


Relationship 
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CARDINALITY and CELL LINKS REPORT 



Connections Listing by Cell 



Entity AIR_TASKING_ORDER 

to Entity MISSION 

through Relationship COMPRISES 


abbrev: ATO 
abbrev: ATO_MSN 
abbrev: COMP 


CARDINALITY 
lower = 1 
upper = 1 
lower n = 1 
upper n = 1 


CARDINALITY 
lower = 1 
upper = N 
lower n = 1 
upper n = 




Entity AJR_TASKING_ORDER 
to Entity RIO_LOGS 
through Relationship UPDATES 


abbrev; ATO 
abbrev; RIO_LOGS 
abbrev; UPDATES 


CARDINALITY 
lower = 1 
upper = 1 
lower n = 1 
upper n = 1 


CARDINALITY 
lower = 1 
upper = N 
lower n = 1 
upper n = 




Entity MISSION 

to Entity IMMEDIATE_REQUESTS 
through Relationship REQUESTS 


abbrev: ATO MSN 
abbrev: IMED AIR 
abbrev: REQUESTS 


CARDINALITY 
lower = 1 
upper = N 
lower n = 1 
upper n = 


CARDINALITY 
lower = 0 
upper = N 
lower n = 0 
upper n = 
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Entity MISSION abbrev: ATO MSN 

parent of Entity RECONNAISSANCE abbrev; RECDATA 

through ISA RELATIONSHIP MISSION abbrev: ATO MSN 



CARDINALITY 
lower = I 
upper = I 
lower n= 1 


CARDINALITY 
lower = 0 
upper = N 
lower n = 0 


upper n= 1 


upper n = 


Entity MISSION 


abbrev: ATO MSN 



parent of Entity MISSION_LOCATION abbrev: MSNLOC 
through ISA RELATIONSHIP MISSION abbrev; ATO MSN 



CARDINALITY 
lower = I 
upper = I 
lower n = 1 


CARDINALITY 
lower = 0 
upper = N 
lower n = 0 


upper n = 1 


upper n = 



Entity MISSION abbrev; ATO_MSN 

to Entity AIR_TASKING_ORDER abbrev; ATO 

through Relationship COMPRISES abbrev; COMP 



CARDINALITY 
lower = 1 
upper = N 
lower n = 1 
upper n = 


CARDINALITY 
lower = I 
upper = I 
lower n = 1 
upper n = I 


Entity MISSION 


abbrev: ATO_MSN 



to Entity ROUTE abbrev: ROUTE 

through Relationship MAY_DESIGNATE abbrev: DESIGNAT 



CARDINALITY 
lower = 1 
upper = 1 
lower n = I 


CARDINALITY 
lower = 0 
upper = N 
lower n = 0 


upper n = I 


upper n = 
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Entity MISSION abbrev: ATO MSN 

parent of Entity TARGET_LOCATION abbrev; TGTLOC 
through ISA RELATIONSHIP MISSION abbrev: ATO MSN 



CARDINALITY 
lower = 1 
upper = 1 
lower n = 1 
upper n = 1 



CARDINALITY 
lower = 0 
upper = N 
lower n = 0 
upper n = 



Entity MISSION 

to Entity CONTROL. AGENCY 

through Relationship CONTROLS 



abbrev; ATO.MSN 
abbrev; CONTROL 
abbrev: CONTROLS 



CARDINALITY 
lower = I 
upper = 1 
lower n = 1 
upper n = 1 



CARDINALITY 
lower = 0 
upper = N 
lower n = 0 
upper n = 



Entity BATTLE_DAMAGE_ASSESSMENT abbrev: BDA 
to Entity TARGET.LOCATION abbrev: TGTLOC 

through Relationship ASSESSES abbrev: ASSESSES 



CARDINALITY 
lower = 0 
upper = N 
lower n = 0 
upper n = 



CARDINALITY 
lower = I 
upper = 1 
lower n = 1 
upper n = I 



Entity CONTROL.AGENCY 

to Entity MISSION 

through Relationship CONTROLS 



abbrev: CONTROL 
abbrev: ATO.MSN 
abbrev: CONTROLS 



CARDINALITY 
lower = 0 
upper = N 
lower n = 0 
upper n = 



CARDINALITY 
lower = 1 
upper = 1 
lower n = 1 
upper n = 1 
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Entity IMMEDIATE_REQUESTS 

to Entity MISSION 

through Relationship REQUESTS 



CARDINALITY 
lower = 0 
upper = N 
lower n = 0 
upper n = 



CARDINALITY 
lower = 1 
upper = 1 
lower n = 1 
upper n = 1 



CARDINALITY 
lower = 0 
upper = N 
lower n = 0 
upper n = 



CARDINALITY 
lower = 1 
upper = N 
lower n = 1 
upper n = 



CARDINALITY 
lower = 0 
upper = N 
lower n = 0 
upper n = 



CARDINALITY 
lower = 1 
upper = 1 
lower n = 1 
upper n = 1 



abbrev; IMED AIR 
abbrev: ATO_MSN 
abbrev: REQUESTS 



abbrev: MSNLOC 
abbrev: REFULEE 
abbrev: REFUELS 



abbrev: MSNLOC 
abbrev: ATO_MSN 
abbrev: ATO.MSN 



Entity MISSION_LOCATION 
to Entity RECEIVING_AIRCRAFT 
through Relationship REFUELS 



Entity MISSION_LOCATION 

chUd of Entity MISSION 

through ISA RELATIONSHIP MISSION 



Entity RECONNAISSANCE abbrev: RECDATA 

to Entity RECON_TARGET abbrev: RECTGT 

through Relationship INTEREST_IN abbrev: INT 



CARDINALITY 
lower = 1 
upper = N 
lower n = 1 
upper n = 



CARDINALITY 
lower = 1 
upper = N 
lower n = 1 
upper n = 
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Entity RECONNAISSANCE abbrev: RECDATA 

chUd of Entity MISSION abbrev: ATO MSN 

through ISA RELATIONSHIP MISSION abbrev: ATO_MSN 



CARDINALITY 
lower = 0 
upper = N 
lower n = 0 
upper n = 



CARDINALITY 
lower = 1 
upper = N 
lower n = 1 
upper n = 



CARDINALITY 
lower = 0 
upper = N 
lower n = 0 
upper n = 



CARDINALITY 
lower = 1 
upper = N 
lower n = 1 
upper n = 



CARDINALITY 
lower = 1 
upper = 1 
lower n = 1 
upper n = 1 



CARDINALITY 
lower = 1 
upper = N 
lower n = 1 
upper n = 



CARDINALITY 
lower = 1 
upper = 1 
lower n = 1 
upper n = 1 



CARDINALITY 
lower = 1 
upper = 1 
lower n = 1 
upper n = 1 



abbrev: RECTGT 
abbrev: RECDATA 
abbrev: INT 



abbrev: REFULEE 
abbrev: MSNLOC 
abbrev: REFUELS 



abbrev: RIO_LOGS 
abbrev: ATO 
abbrev: UPDATES 



Entity RECON TARGET 
to Entity RECONNAISSANCE 
through Relationship INTEREST_IN 



Entity RECEIVING_AIRCRAFT 
to Entity MISSION_LOCATION 
through Relationship REFUELS 



Entity RIOLOGS 

to Entity AIR_TASKING_ORDER 
through Relationship UPDATES 
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Entity ROUTE abbrev: ROUTE 

to Entity MISSION abbrev: ATO_MSN 

through Relationship MAY_DESIGNATE abbrev: DESIGNAT 



CARDINALITY 
lower = 0 
upper = N 
lower n = 0 
upper n = 



CARDINALITY 
lower = 1 
upper = 1 
lower n = 1 
upper n = 1 



Entity TARGET_LOCATION abbrev: TGTLOC 

child of Entity MISSION abbrev: ATO_MSN 

through ISA RELATIONSHIP MISSION abbrev: ATO.MSN 



CARDINALITY 
lower = 0 
upper = N 
lower n = 0 
upper n = 



CARDINALITY 
lower = 1 
upper = 1 
lower n = 1 
upper n = 1 



Entity TARGET_LOCATION abbrev: TGTLOC 

to Entity BATTLE_DAMAGE_ASSESSMENT abbrev: BDA 
through Relationship ASSESSES abbrev: ASSESSES 



CARDINALITY 
lower = 1 
upper = 1 
lower n = 1 

upper n= I 



CARDINALITY 
lower = 0 
upper = N 
lower n = 0 
upper n = 



ISA RELATIONSHIP MISSION’S abbrev: ATO_MSN 

parent is Entity MISSION abbrev: ATO_MSN 



ISA RELATIONSHIP MISSION’S abbrev: ATO.MSN 

chUd is Entity TARGET_LOCATION abbrev: TGTLOC 



ISA RELATIONSHIP MISSION’S abbrev: ATO_MSN 

chUd is Entity MISSION.LOCATION abbrev: MSNLOC 
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ISA RELATIONSHIP MISSION’S 
parent is Entity MISSION 



abbrev: ATO_MSN 
abbrev: ATO MSN 



ISA RELATIONSHIP MISSION’S 



abbrev: ATO MSN 



child is Entity RECONNAISSANCE abbrev: RECDATA 



CARDINALITY 
lower = 1 
upper = 1 
lower n = 1 
upper n = 1 

Relationship ASSESSES abbrev: ASSESSES 

to Entity B A 1 1 LE_D AMAG E_ AS S ES S MENT abbrev: BDA 

CARDINALITY 
lower = 0 
upper = N 
lower n = 0 
upper n = 

Relationship COMPRISES abbrev: COMP 

to Entity AIR_TASKING_ORDER abbrev: ATO 

CARDINALITY 
lower = 1 
upper = 1 
lower n = 1 
upper n = 1 



ISA RELATIONSHIP MISSION’S 
parent is Entity MISSION 



abbrev: ATO_MSN 
abbrev: ATO_MSN 



Relationship ASSESSES 
to Entity TARGET_LOCATION 



abbrev: ASSESSES 
abbrev: TGTLOC 
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Relationship COMPRISES 
to Entity MISSION 



abbrev; COMP 
abbrev: ATO MSN 



CARDINALITY 
lower = 1 
upper = N 
lower n = 1 
upper n = 

Relationship CONTROLS abbrev: CONTROLS 

to Entity MISSION abbrev: ATO_MSN 

CARDINALITY 
lower = 1 
upper = 1 
lower n = 1 
upper n = 1 

Relationship CONTROLS abbrev: CONTROLS 

to Entity CONTROL. AGENCY abbrev: CONTROL 

CARDINALITY 
lower = 0 
upper = N 
lower n = 0 
upper n = 



CARDINALITY 
lower = 1 
upper = 1 
lower n = 1 
upper n = 1 



Relationship MAY-DESIGNATE 
to Entity MISSION 



abbrev: DESIGNAT 
abbrev: ATO MSN 
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Relationship MAY_DESIGNATE 
to Entity ROUTE 



abbrev; DESIGNAT 
abbrev; ROUTE 



CARDINALITY 
lower = 0 
upper = N 
lower n = 0 
upper n = 

Relationship INTERESTJN abbrev: INT 

to Entity RECON_TARGET abbrev: RECTGT 

CARDINALITY 
lower = 1 
upper = N 
lower n = 1 
upper n = 

Relationship INTEREST_IN abbrev: INT 



CARDINALITY 
lower = 1 
upper = N 
lower n = 1 
upper n = 

Relationship REFUELS abbrev: REFUELS 

to Entity RECEIVING_AIRCRAFT abbrev: REFULEE 

CARDINALITY 
lower = 0 
upper = N 
lower n = 0 
upper n = 



to Entity RECONNAISSANCE 



abbrev: RECDATA 
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Relationship REFUELS 
to Entity MISSION_LOCATION 



abbrev; REFUELS 
abbrev; MSNLOC 



CARDINALITY 
lower = 1 
upper = 1 
lower n = 1 
upper n = 1 

Relationship REQUESTS abbrev: REQUESTS 

to Entity IMMEDIATE_REQUESTS abbrev: IMED AIR 

CARDINALITY 
lower = 0 
upper = N 
lower n = 0 
upper n = 

Relationship REQUESTS abbrev: REQUESTS 

to Entity MISSION abbrev: ATO_MSN 

CARDINALITY 
lower = 1 
upper = N 
lower n = 1 
upper n = 



CARDINALITY 
lower = 1 
upper = 1 
lower n = 1 
upper n = 1 



Relationship UPDATES 

to Entity AIR_TASKING_ORDER 



abbrev: UPDATES 
abbrev: ATO 
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Relationship UPDATES 
to Entity RIO_LOGS 



abbrev; UPDATES 
abbrev: RIOLOGS 



CARDINALITY 
lower = 1 
upper = N 
lower n = 1 
upper n = 
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APPENDIX E: E-R DESIGNER RELATIONAL SCHEMA 



CONTROL_AGENCY {callsign : control_agency, primary_frequency, secondaiy_frequency, 
control_point) 

AIR_TASKING_ORDER {ato_start, ato_stop, air_tasking_code :) 

ROUTE {missionjmmber , point jmmber : control_point_type, location, arrival_time) 

RIO_LOGS {missionjmmber : actual_time_of_arrival, actual_time_of_retum) 

RECEIVING_AIRCRAFT {missionjmmber, a!c_callsign : number_of_aircraft, aircraft_type, 
amount_of_fuel, fuel_requirements, refueling time) 

BATTLE_DAMAGE_ASSESSMENT {location, time-on-target ; time-off-target, 
percent_ordnance_on_target, percent_target_destroyed, bda_comment, unit_supported) 

MISSION_LOCATION {request jmmber, missionjmmber, alcjcallsign : location_type, 
location, altitude, mission_comment) 

MISSION {missionjmmber, alcjcallsign, request number : number_of_aircraft, aircraft_type, 
mission_type, alert_status, primary _configuration_code, secondary_configuration_code, 
iff/sif_codes, est_time_airbome, est_time_of_retum) 

TARGET_LOCATION {target jdentifier, missionjmmber , alcjcallsign, request jmmber : 
time-on-target, time-off-target, target_type, location, target_comments) 

RECONNAISSANCE {request jumber : priority, mission_start, mission_stop, 
latest_time_info_of_value, mission_type, coverage_type) 

IMMEDIATE_REQUESTS {immediate jir jequest jumber : unit_supported) 

RECON_TARGET {location : target_length, target_width) 

Key 

RELATION {primary key attribute(s) : non-key attribute(s)) 
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COMPRISES {ato_start, ato_stop, air _tasking_code, missionjmmber , a/c_callsign :) 
ASSESSES {tar get identifier , location, time-on-target, time- off-tar get :) 

CONTROLS {mission _number, alc_callsign, callsign :) 

REQUESTS {immediate _air _reque St jmmber , missionjmmber, alcj:allsign :) 
INTEREST_IN {location, request jnimber :) 

MAY_DESIGNATE {missionjmmber, alcjeallsign, point jmmber :) 

UPDATES {atojtart. ato_stop, airjaskingjoode, missionjmmber :) 

REFUELS {missionjmmber, alcjsallsign, request jmmber :) 
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E-R Designer Relational Schema File Format 



CONTROL_AGENCY 5 1 

CALLSIGN C,15 

CONTROL_AGENCY C,4 

PRIMARY_FREQUENCY C,8 

SECONDARY_FREQUENCY C,8 

CONTROL.POINT C,20 

AIR_TASKING_ORDER 3 3 

ATO_START C,7 

ATO_STOP C,7 

AIR_TASKING_CODE C,43 

ROUTE 3 2 

MISSION_NUMBER C,8 

POINT_NUMBER N,2 

CONTROL_POINT_TYPE C,3 

LOCATION C,20 

ARRIVAL_TIME C,7 

RIO.LOGS 3 1 

MISSION_NUMBER C,8 

ACTUAL_TIME_OF_ARRIVAL N,4 

ACTUAL_TIME_OF_RETURN N,4 

RECEIVING_AIRCRAFT 7 2 

MISSION_NUMBER C,8 

A/C_CALLSIGN C,I2 

NUMBER_OF_AIRCRAFT N,2 

AIRCRAFT_TYPE C,6 

AMOUNT_OF_FUEL N,4 

FUEL_REQUIREMENTS N,4 

REFUELING_TIME C,7 

— Key 

Relation # of attributes, # of primary key attributes 



Attribute field format, max length 

C (character) 

N (numeric) 
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BATTLE_DAMAGE_ASSESSMENT 7 3 

LOCATION C,20 

TIME-ON-TARGET C,7 

TEME-OFF-TARGET C,7 

PERCENT_ORDNANCE_ON_TARGET N,2 
PERCENT_TARGET_DESTROYED N,2 

BDA_COMMENT C,30 

UNIT_SUPPORTED C,9 

MISSION_LOCATION 7 3 

REQUEST_NUMBER C,6 

MISSION_NUMBER C,8 

A/C_CALLSIGN C,12 

LOCATION_TYPE C,6 

LOCATION C,20 

ALTITUDE C,5 

MISSION_COMMENT C,22 

MISSION 13 3 

MISSION_NUMBER C,8 

A/C_CALLSIGN C,12 

REQUEST NUMBER C,6 

NUMBER_OF_AIRCRAFT C,2 

AIRCRAFT_TYPE C,6 

MISSION_TYPE C,5 

ALERT_STATUS C,3 

PRIMARY_CONnGURATION_CODE C,5 
SECONDARY_CONnGURATION_CODE C,5 
IFF/SIF_CODES C,5 

EST_TIME_AIRBORNE N,4 

EST_TIME_OF_RETURN N,4 

TARGET_LOCATION 9 4 

TARGETJDENTIFIER C,20 

MISSION_NUMBER C,8 

A/C_CALLSIGN C,12 

REQUEST_NUMBER C,6 

TIME-ON-TARGET C,7 

TEME-OFF-TARGET C,7 

TARGET_TYPE C,6 

LOCATION C,20 

TARGET_COMMENTS C,35 
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RECONNAISSANCE 7 1 

REQUEST_NUMBER C,6 

PRIORITY C,1 

MISSION_START C,7 

MISSION_STOP C,7 

LATEST_TIME_INFO_OF_VALUE C,ll 

MISSION_TYPE C,5 

COVERAGE_TYPE C,7 

IMMEDIATE_REQUESTS 2 1 

IMMEDIATE_AIR_REQUEST_NUMBER C,5 
UNTT_SUPPORTED C,9 

RECON.TARGET 3 1 

LOCATION C,20 

TARGET_LENGTH C,7 

TARGET_WIDTH C,7 

COMPRISES 5 5 

ATO.START C,7 

ATO.STOP C,7 

AIR_TASKING_CODE C,43 

MISSION_NUMBER C,8 

A/C_CALLSIGN C,12 

ASSESSES 4 4 

TARGETJDENTIFIER C,20 

LOCATION C,20 

TIME-ON-TARGET C,7 

TIME-OFF-TARGET C,7 

CONTROLS 3 3 

MISSION_NUMBER C,8 

A/C_CALLSIGN C,12 

CALLSIGN C,15 

REQUESTS 3 3 

IMMEDIATE_AIR_REQUEST_NUMBER C,5 
MISSION_NUMBER C,8 

A/C_CALLSIGN C,12 
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INTERESTJN 2 2 

LOCATION C,20 

REQUEST_NUMBER C,6 

MAY_DESIGNATE 3 3 

MISSION_NUMBER C,8 

A/C_CALLSIGN C,12 

POINT_NUMBER N,2 

UPDATES 4 4 

ATO_START C,7 

ATO_STOP C,7 

AIR_TASKING_CODE C,43 

MISSION_NUMBER C,8 

REFUELS 3 3 

MISSION_NUMBER C,8 

A/C_CALLSIGN C,12 

REQUEST_NUMBER C,6 



98 



APPENDIX F: NORMALIZER LOG 



ENTERING FD FOR THE RELATION: CONTROL_AGENCY 

CONTROL. AGENCY (CALLSIGN, CONTROL.AGENCY, PRIMARY.FREQUENCY, 
SECONDARY.FREQUENCY, CONTROL.POINT) 



Candidate keys= 

1 CALLSIGN 

All Fd’s entered for this relation 

1: CALLSIGN — > CONTOOL. AGENCY PRIMARY.FREQUENCY 
SECONDARY.FREQUENCY 
2: CONTROL.AGENCY — > CONTROL.POINT 



RESULT OF CHECKING NORMAL FORMS FOR RELATION (CONTROL.AGENCY) 

NOTATION: Y : SATISFACTORY N : NOT SATISFACTORY 

FD no. BCNF 3NF 

1 Y Y 

2 N N 

Removing the EXTRANEOUS ATTRIBUTES begins 

No extraneous attribute found 



SEARCHING for REDUNDANT FDs begins 

NO redundant FD found. 

CONSTRUCTION OF RELATIONS begins 

The relation (CONTROL.AGENCY) was SYNTHESIZED and MINIMIZED as follows: 
Original Relation is decomposed to : 

(CALLSIGN : CONTROL. AGENCY, PRIMARY.FREQUENCY, 

SECOND ARY.FREQUENCY) 

(CONTROL.AGENCY : CONTROL.POINT) 

Checking for LOSSLESS JOIN begins.... 

Decomposition is LOSSLESS 
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The relations are SYNTHESIZED, 

FD-PRESERVING, LOSSLESS, and MINIMAL relations 

Now, ASSIGN the relation name for new relation(s). 

New Decomposed Relations: 

(CALLSIGN ; CONTROL_AGENCY, PRIMARY_FREQUENCY, 
SECONDARY_FREQUENCY) 

Enter A new name for the relation above ===> 

New Decomposed Relations: 

(CONTROL_AGENCY : CONTROL_POINT) 

Enter A new name for the relation above ==> 

FDs after Normalization 

1. CALLSIGN — > CONTROL_AGENCY PRIMARY_FREQUENCY 
SECOND ARY_FREQUENCY 

2. CONTROL_AGENCY — > CONTROL_POINT 



ENTERING FD FOR THE RELATION: AIR_TASKING_ORDER 
AIR_TASKING_ORDER (ATO_START, ATO_STOP, AIR_TASKING_CODE) 



ENTERING FD FOR THE RELATION: ROUTE 

ROUTE (MISSION_NUMBER, POINT_NUMBER, CONTROL_POINT_TYPE, LOCATION, 
ARRIVAL_TIME) 



ENTERING FD FOR THE RELATION: RIO_LOGS 

RIO_LOGS (MISSION_NUMBER, ACTUAL_TIME_OF_ARRIVAU, 
ACTUAL_TIME_OF_RETURN) 



ENTERING FD FOR THE RELATION: RECEIVING_AIRCRAFT 

RECEIVING_AIRCRAFT (MISSION_NUMBER, A/C_CALLSIGN, 
NUMBER_OF_AIRCRAFT, AIRCRAFT_TYPE, AMOUNT_OF_FUEL, 
FUEL.REQUIREMENTS, REFUELING_TIME) 

Candidate keys= 

1 MISSION_NUMBER A/C_CALLSIGN 
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All Fd’s entered for this relation 

1; MISSION.NUMBER A/C_CALLSIGN — > NUMBER_OF_AIRCRAFT 
AIRCRAFT_TYPE AMOUNT_OF_FUEL REFUELING_TIME 

2: NUMBER_OF_AIRCRAFT AMOUNT_OF_FUEL — > FUEL_REQU1REMENTS 



RESULT OF CHECKING NORMAL FORMS FOR RELATION 
(RECEIV1NG_A1RCRAFT) 

NOTATION: Y : SATISFACTORY N : NOT SATISFACTORY 

FD no. BCNF 3NF 

1 Y Y 

2 N N 

Removing the EXTRANEOUS ATTRIBUTES begins 

No extraneous attribute found 



SEARCHING for REDUNDANT FDs begins 

NO redundant FD found. 

CONSTRUCTION OF RELATIONS begins 

The relation (RECEIVING.AIRCRAFT) was SYNTHESIZED and MINIMIZED as follows: 
Original Relation is decomposed to : 

(MISSION_NUMBER, A/C_CALLSIGN : NUMBER_OF_AIRCRAFT, AIRCRAFT_TYPE, 
AMOUNT_OF_FUEL, REFUELING_TTME) 

(NUMBER_OF_AIRCRAFT, AMOUNT_OF_FUEL : FUEL_REQUIREMENTS) 

Checking for LOSSLESS JOIN begins.... 

Decomposition is LOSSLESS 
The relations are SYNTHESIZED, 

FD-PRESERVING, LOSSLESS, and MINIMAL relations 

Now, ASSIGN the relation name for new relation(s). 

New Decomposed Relations: 

(MISSION_NUMBER, A/C_CALLSIGN : NUMBER_OF_AIRCRAFT, AIRCRAFT.'TYPE, 
AMOUNT_OF_FUEL, REFUELING_TIME) 

Enter A new name for the relation above ===> 

New Decomposed Relations: 

(NUMBER_OF_AIRCRAFT, AMOUNT_OF_FUEL : FUEL_REQUIREMENTS) 

Enter A new name for the relation above ==> 
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FDs after Normalization 

1. MISSION_NUMBER A/C_CALLSIGN — > NUMB ER_OF_ AIRCRAFT 
AIRCRAFT_TYPE AMOUNT_OF_FUEL REFUELING.TIME 

2. NUMBER_OF_AIRCRAFT AMOUNT_OF_FUEL — > FUEL_REQUIREMENTS 



ENTERING FD FOR THE RELATION: BATTLE_DAMAGE_ASSESSMENT 

BATTLE_DAMAGE_ASSESSMENT (LOCATION, TIME-ON-TARGET, 
TIME-OFF-TARGET, PERCENT_ORDANANCE_ON_TARGET, 
PERCENT_TARGET_DESTROYED, BDA_COMMENT, UNIT_SUPPORTED) 



ENTERING FD FOR THE RELATION: MISSION_LOCATION 

MISSION_LOCATION (MISSION_NUMBER, A/C_CALLSIGN, REQUEST_NUMBER, 
LOCATION_TYPE, LOCATION, ALTITUDE, MISSION_COMMENT) 



Candidate keys= 

1 MISSION_NUMBER A/C_CALLSIGN REQUEST_NUMBER 

All Fd’s entered for this relation 
1: REQUEST_NUMBER — > LOCATION_TYPE LOCATION 

2: MISSION_NUMBER A/C_CALLSIGN REQUEST_NUMBER — > ALTITUDE 
MISSION_COMMENT 



RESULT OF CHECKING NORMAL FORMS FOR RELATION (MISSION_LOCATION) 

NOTATION: Y : SATISFACTORY N : NOT SATISFACTORY 

FD no. BCNF 3NF 

1 N N 

2 Y Y 

Removing the EXTRANEOUS ATTRIBUTES begins 

No extraneous attribute found 



SEARCHING for REDUNDANT FDs begins... 
NO redundant FD found. 

CONSTRUCTION OF RELATIONS begins 
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The relation (MISSION_LOCATION) was SYNTHESIZED and MINIMIZED as foUows: 
Original Relation is decomposed to ; 

(REQUEST_NUMBER : LOCATION_TYPE, LOCATION) 

(MISSION_NUMBER, A/C_CALLSIGN, REQUEST_NUMBER : ALTITUDE, 
MISSION_COMMENT) 

Checking for LOSSLESS JOIN begins.... 

Decomposition is LOSSLESS 
The relations are SYNTHESIZED, 

FD-PRESERVING, LOSSLESS, and MINIMAL relations 

Now, ASSIGN the relation name for new relation(s). 

New Decomposed Relations; 

(REQUEST_NUMBER : LOCATION_TYPE, LOCATION) 

Enter A new name for the relation above ===> 

New Decomposed Relations: 

(MISSION_NUMBER, A/C_CALLSIGN, REQUEST_NUMBER : ALTITUDE, 
MISSION_COMMENT) 

Enter A new name for the relation above ==> 

FDs after Normalization 

1. REQUEST_NUMBER — > LOCATION_TYPE LOCATION 

2. MISSION_NUMBER A/C_CALLSIGN REQUEST_NUMBER — > ALTITUDE 
MISSION_COMMENT 



ENTERING FD FOR THE RELATION: MISSION 

MISSION (MISSION_NUMBER, A/C_CALLSIGN, REQUEST_NUMBER, 
NUMBER_OF_AIRCRAFT, A1RCRAFT_TYPE, MISSION_TYPE, ALERT_STATUS, 
PRIMARY_CONnGURATION_CODE, SECONDARY.CONHGURATION.CODE, 
1FF/SIF_C0DES, EST_T1ME_ AIRBORNE, EST_TIME_OF_RETURN) 



Candidate keys= 

1 MISSION_NUMBER A/C_CALLSIGN REQUEST_NUMBER 



All Fd’s entered for this relation 

1; MlSSION_NUMBER A/C_CALLSIGN — > NUMBER_OF_AIRCRAFT 
AIRCRAFT_TYPE MISSION_TYPE ALERT_STATUS 

PRIMARY_CONFIGURATION_CODE SECONDARY_CONnGURATION_CODE 
IFF/SIF_CODES 

2; A/C_CALLSIGN — > NUMBER_OF_AIRCRAFT AIRCRAFT_TYPE 
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3; MISSION NUMBER — > MISSION TYPE 



RESULT OF CHECKING NORMAL FORMS FOR RELATION ( MISSION ) 
NOTATION: Y : SATISFACTORY N : NOT SATISFACTORY 

FD no. BCNF 3NF 

1 N N 

2 N N 

3 N N 

Removing the EXTRANEOUS ATTRIBUTES begins 

Extraneous attribute(s) found 

*** Before Removing Extraneous Attributes: *** 

1: MISSION_NUMBER A/C_C ALLSIGN — > NUMB ER_OF_ AIRCRAFT 
AIRCRAFT.TYPE MISSION_TYPE ALERT_STATUS 

PRIMARY_CONnGURATION_CODE SECONDARY.CONHGURATION.CODE 
IFF/SIF_CODES EST_TIME_AIRBORNE EST_TIME_OF_RETURN 
2; A/C_CALLSIGN — > NUMBER_OF_AIRCRAFT AIRCRAFT_TYPE 
3: MISSION_NUMBER — > MISSION_TYPE 
*** After Removing Extraneous Attributes: *** 

1: MISSION_NUMBER A/C_CALLSIGN — > ALERT_STATUS 
PRIMARY_CONnGURATION_CODE SECONDARY.CONHGURATION.CODE 
IFF/SIF_CODES EST_TIME_AIRBORNE EST_TIME_OF_RETURN 
2: A/C_CALLSIGN — > NUMBER_OF_AIRCRAFT AIRCRAFT_TYPE 
3: MISSION_NUMBER — > MISSION_TYPE 

SEARCHING for REDUNDANT FDs begins 

NO redundant ID found. 



CONSTRUCTION OF RELATIONS begins 

The relation (MISSION) was SYNTHESIZED and MINIMIZED as follows: 
Original Relation is decomposed to : 

(MISSION_NUMBER, A/C_CALLSIGN, REQUEST_NUMBER) 
(MISSION_NUMBER, A/C_CALLSIGN : ALERT_STATUS, 
PRIMARY_CONnGURA'nON_CODE, SECONDARY_CONnGURATION_CODE, 
IFF/SIF_CODES, EST_TIME_AIRBORNE, EST_TEME_OF_RETURN) 
(A/C_CALLSIGN : NUMBER_OF_AIRCRAFT, AIRCRAFT_TYPE) 
(MISSION_NUMBER : MISSION.TYPE) 

Checking for LOSSLESS JOIN begins.... 



Decomposition is LOSSLESS 
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The relations are SYNTHESIZED, 

FD-PRESERVING, LOSSLESS, and MINIMAL relations 



Now, ASSIGN the relation name for new relation(s). 

New Decomposed Relations; 

(MISSION_NUMBER, A/C_CALLSIGN, REQUEST_NUMBER) 

Enter A new name for the relation above ===> 

New Decomposed Relations; 

(MISSION_NUMBER, A/C_CALLSIGN ; ALERT_STATUS, 

PRlMARY_CONnGURAT10N_CODE, SECONDARY_CONnGURATION_CODE, 

IFF/SIF_CODES, EST_TIME_AIRBORNE, EST_TIME_OF_RETURN) 

Enter A new name for the relation above ===> 

New Decomposed Relations; 

(A/C_CALLSIGN : NUMBER_OF_AIRCRAFT, AIRCRAFT.TYPE) 

Enter A new name for the relation above ===> 

New Decomposed Relations; 

(MISSION_NUMBER ; MISSION_TYPE) 

Enter A new name for the relation above ===> 



FDs after Nonnalization 

1. MISSION_NUMBER A/C_CALLSIGN — > ALERT_STATUS 
PRIMARY_CONnGURA'nON_CODE SECOND ARY_CONnGURATION_CODE 
IFF/SIF_CODES EST_TIME_AIRBORNE EST_TIME_OF_RETURN 

2. A/C_CALLSIGN — > NUMBER_OF_AIRCRAFT AIRCRAFT_TYPE 

3. MISSION_NUMBER — > MISSION_TYPE 



ENTERING FD FOR THE RELATION; TARGET_LOCATION 

TARGET_LOCATION (TARGETJDENTIFIER, MISSION_NUMBER, A/C_CALLSIGN, 
REQUEST_NUMBER, TIME-ON-TARGET, TIME-OFF-TARGET, TARGET_TYPE, 
LOCATION, TARGET_COMMENTS) 



Candidate keys= 

1 TARGETJDENTIFIER MISSION_NUMBER A/C_CALLSIGN REQUEST_NUMBER 



All Fd’s entered for this relation 

1; TARGET_IDENTinER — > TIME-ON-TARGET HME-OFF-TARGET TARGET_TYPE 
LOCATION TARGET_COMMENTS 



105 



RESULT OF CHECKING NORMAL FORMS FOR RELATION (TARGET_LOCATION) 



NOTATION; Y ; SATISFACTORY N : NOT SATISFACTORY 
FD no. BCNF 3NF 

1 N N 

Removing the EXTRANEOUS ATTRIBUTES begins 

No extraneous attribute found 

SEARCHING for REDUNDANT FDs begins 

NO redundant FD found. 

CONSTRUCTION OF RELATIONS begins 

The relation (TARGET_LOCATION) was SYNTHESIZED and MINIMIZED as follows: 
Original Relation is decomposed to : 

(TARGET_IDENTinER, MISSION_NUMBER, A/C_CALLSIGN, REQUEST_NUMBER) 
(TARGET_IDENTIFIER ; TIME-ON-TARGET, TIME-OFF-TARGET, TARGET_TYPE, 
LOCATION, TARGET_COMMENTS) 

Checking for LOSSLESS JOIN begins.... 

Decomposition is LOSSLESS 
The relations are SYNTHESIZED, 

FD-PRESERVING, LOSSLESS, and MINIMAL relations 

Now, ASSIGN the relation name for new relation(s). 

New Decomposed Relations: 

(TARGETJDENTinER, MISSION_NUMBER, A/C_CALLSIGN, REQUEST_NUMBER) 
Enter A new name for the relation above ===> 

New Decomposed Relations: 

(TARGET_IDENTinER : TIME-ON-TARGET, TIME-OFF-TARGET, TARGET_TYPE, 
LOCATION, TARGET_COMMENTS) 

Enter A new name for the relation above ===> 

FDs after Normalization 

1. TARGET_IDENTIFIER — > TTME-ON-TARGET TIME-OFF-TARGET TARGET_TYPE 
LOCATION TARGET_COMMENTS 



ENTERING FD FOR THE RELATION: IMMEDIATE_REQUESTS 
IMMEDIATE_REQUESTS (IMMEDIATE_AIR_REQUEST_NUMBER, UNIT_SUPPORTED) 
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Candidate keys= 

1 IMMEDIATE. AIR_REQUEST_NUMBER 



All Fd’s entered for this relation 

1: IMMEDIATE_AIR_REQUEST_NUMBER — > UNTT.SUPPORTED 



RESULT OF CHECKING NORMAL FORMS FOR RELATION 
(IMMEDIATE.REQUESTS ) 

NOTATION; Y : SATISFACTORY N ; NOT SATISFACTORY 
FD no. BCNF 3NF 

1 Y Y 

Removing the EXTRANEOUS ATTRIBUTES begins 

No extraneous attribute found 



SEARCHING for REDUNDANT FDs begins 
NO redundant FD found. 



FDs after Normalization 

1. IMMEDIATE_AJR_REQUEST_NUMBER — > UNTT.SUPPORTED 



ENTERING FD FOR THE RELATION; RECONNAISSANCE 

RECONNAISSANCE (REQUEST.NUMBER, PRIORITY, MISSION.START, 
MISSION.STOP, LATEST_TIME_INFO_OF_VALUE, MISSION.TYPE, 
COVERAGE.TYPE) 



Candidate keys= 

I REQUEST.NUMBER 

All Fd’s entered for this relation 

1: REQUEST.NUMBER — > PRIORITY MISSION.START MISSION.STOP 
LATEST_TIME_INFO_OF_VALUE MISSION.TYPE COVERAGE.TYPE 



RESULT OF CHECKING NORMAL FORMS FOR RELATION ( RECONNAISSANCE ) 

NOTATION; Y ; SATISFACTORY N ; NOT SATISFACTORY 
FD no. BCNF 3NF 
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1 



Y Y 



Removing the EXTRANEOUS ATTRIBUTES begins 

No extraneous attribute found 

SEARCHING for REDUNDANT FDs begins 

NO redundant FD found. 

FDs after Normalization 

1. REQUEST_NUMBER — > PRIORITY MISSION_START MISSION_STOP 
LATEST_TIME_INFO_OF_VALUE MISSION_TYPE COVERAGE_TYPE 



ENTERING FD FOR THE RELATION: RECON_TARGET 

RECON_TARGET (LOCATION, TARGET_LENGTH, TARGET_WIDTH) 

Candidate keys= 

1 LOCATION 

All Fd’s entered for this relation 
I : LOCATION — > TARGET_LENGTH TARGET_WIDTH 



RESULT OF CHECKING NORMAL FORMS FOR RELATION (RECON_TARGET) 
NOTATION: Y : SATISFACTORY N : NOT SATISFACTORY 

FD no. BCNF 3NF 

1 Y Y 

Removing the EXTRANEOUS ATTRIBUTES begins 

No extraneous attribute found 

SEARCHING for REDUNDANT FDs begins 

NO redundant FD found. 

FDs after Normalization 

1. LOCATION — > TARGET_LENGTH TARGET_WIDTH 



ENTERING FD FOR THE RELATION: COMPRISES 
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COMPRISES (ATO_START, ATO_STOP, AIR_TASKING_CODE, MISSION_NUMBER, 
A/C_CALLSIGN) 



ENTERING FD FOR THE RELATION; ASSESSES 

ASSESSES (TARGETJDENTinER, LOCATION, TIME-ON-TARGET, 
TIME-OFF-TARGET) 



Candidate keys= 

1 TARGETJDENTIFIER TIME-ON-TARGET TIME-OFF-TARGET 



All Fd’s entered for this relation 
1: TARGETJDENTinER — > LOCATION 



RESULT OF CHECKING NORMAL FORMS FOR RELATION ( ASSESSES ) 
NOTATION: Y : SATISFACTORY N : NOT SATISFACTORY 

FD no. BCNF 3NF 

INN 

Removing the EXTRANEOUS ATTRIBUTES begins 

No extraneous attribute found 

SEARCHING for REDUNDANT FDs begins 

NO redundant FD found. 

CONSTRUCTION OF RELATIONS begins 

The relation (ASSESSES) was SYNTHESIZED and MINIMIZED as follows; 
Original Relation is decomposed to : 

(TARGETJDENTIFIER, TIME-ON-TARGET, TIME-OFF-TARGET) 
(TARGETJDENTIFIER ; LOCATION) 

Checking for LOSSLESS JOIN begins.... 

Decomposition is LOSSLESS 
The relations are SYNTHESIZED, 

FD-PRESERVING, LOSSLESS, and MINIMAL relations 

Now, ASSIGN the relation name for new relation(s). 

New Decomposed Relations: 

(TARGET_IDENTIFIER, TIME-ON-TARGET, TIME-OFF-TARGET) 

Enter A new name for the relation above ===> 
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New Decomposed Relations; 
(TARGETJOENTEFIER : LOCATION) 

Enter A new name for the relation above ===> 

FDs after Normalization 
1. TARGET IDENTIFIER — > LOCATION 



ENTERING FD FOR THE RELATION: CONTROLS 
CONTROLS (MISSION_NUMBER, A/C_CALLSIGN, CALLSIGN) 

ENTERING FD FOR THE RELATION; REQUESTS 

REQUESTS (IMMEDIATE_AIR_REQUEST_NUMBER, MISSION.NUMBER, 
A/C_CALLSIGN) 

ENTERING FD FOR THE RELATION: INTERESTJN 

INTEREST_IN (LOCATION, REQUEST_NUMBER) 

Candidate keys= 

1 REQUEST_NUMBER 

All Fd’s entered for this relation 
1: REQUEST_NUMBER — > LOCATION 



RESULT OF CHECKING NORMAL FORMS FOR RELATION ( INTEREST_IN ) 
NOTATION: Y : SATISFACTORY N : NOT SATISFACTORY 

FD no. BCNF 3NF 

1 Y Y 

Removing the EXTRANEOUS ATTRIBUTES begins 

No extraneous attribute found 



SEARCHING for REDUNDANT FDs begins 
NO redundant FD found. 



no 



FDs after Normalization 
1. REQUEST_NUMBER —> LOCATION 

ENTERING FD FOR THE RELATION: MAY_DES1GNATE 
MAY_DESIGNATE (A/C_CALLSIGN, MISSION_NUMBER, POINT_NUMBER) 



ENTERING FD FOR THE RELATION: UPDATES 

UPDATES (ATO_START, ATO_STOP, AIR_TASKING_CODE, MISSION_NUMBER) 



ENTERING FD FOR THE RELATION: REFUELS 

REFUELS (MISSION_NUMBER, A/C_CALLSIGN, REQUEST.NUMBER) 
Candidate keys= 

1 A/C_CALLSIGN REQUEST_NUMBER 
All Fd’s entered for this relation 

1: A/C_CALLSIGN REQUEST_NUMBER — > MISSION_NUMBER 



RESULT OF CHECKING NORMAL FORMS FOR RELATION ( REFUELS ) 
NOTATION: Y : SATISFACTORY N : NOT SATISFACTORY 

FD no. BCNF 3NF 

1 Y Y 

Removing the EXTRANEOUS ATTRIBUTES begins 

No extraneous attribute found 

SEARCHING for REDUNDANT FDs begins 

NO redundant FD found. 

FDs after Normalization 

1. A/C_CALLSIGN REQUEST_NUMBER — > MISSION_NUMBER 
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Normalizer Functional Dependencies Summary 



ASSESSES FDs 

TARGETJDENTIFIER 
— > 

LOCATION 



CONTROLS FDs 

CALLSIGN 
— > 

CONTROL_AGENCY 
PRIMARY_FREQUENCY 
SECOND ARY_FREQUENCY 

CONTROL_AGENCY 
— > 

CONTROL_POINT 
IMMEDIATE FDs 

IMMEDIATE. AIR_REQUEST_NUMBER 
— > 

UNIT SUPPORTED 



INTEREST FDs 

REQUEST.NUMBER 
— > 

LOCATION 



MISSION FDs 

REQUEST.NUMBER 
— > 

LOCATION.TYPE 

LOCATION 



II2 



MISSION_NUMBER 
A/C_CALLSIGN 
REQUEST_NUMBER 
— > 

ALTITUDE 

MISSION_COMMENT 



MSN FDs 

MISSION_NUMBER 
A/C_CALLSIGN 
— > 

ALERT_STATUS 

PRIMARY_CONnGURAT10N_CODE 
SECOND ARY_CONFIGURATION_CODE 
IFF/SIF_CODES 

A/C_CALLSIGN 
— > 

NUMB ER_OF_AIRCR AFT 
AIRCRAFT_TYPE 

MISSION_NUMBER 
— > 

MISSION_TYPE 



RECEIVING FDs 

MISSION_NUMBER 
A/C_CALLSIGN 
— > 

NUMBER_OF_AIRCRAFT 

AIRCRAFT_TYPE 

AMOUNT_OF_FUEL 

REFUELING_TIME 

NUMBER_OF_AIRCRAFT 
AMOUNT_OF_FUEL 
— > 

FUEL_REQUIREMENTS 
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RECON FDs 



REQUEST_NUMBER 
— > 

PRIORITY 

MISSION.START 

MISSION_STOP 

LATEST_TIME_INFO_OF_ VALUE 

MISSION_TYPE 

COVERAGE_TYPE 



RECONTGT FDs 

LOCATION 
— > 

TARGET_LENGTH 

TARGET_WIDTH 



REFUELS FDs 

A/C_CALLSIGN 
REQUEST_NUMBER 
— > 

MISSION NUMBER 



TARGET FDs 

TARGETJDENTIHER 

— > 

TIME-ON-TARGET 
TIME-OFF-TARGET 
TARGET_TYPE 
LOCATION 
TARGET COMMENTS 



APPENDIX G: NORMALIZED RELATIONAL SCHEMA 



AIR_TASKING_ORDER {ato_start, ato_stop, air_tasking_code :) 

ROUTE {mission jmmber, pointjmmber : control_point_type, location, arrival_time) 

RIO_LOGS {mission jxumber : actual_time_of_arrival, actual_time_of_retum) 

BATTLE_DAMAGE_ASSESSMENT {location, time-on-target, time-off-target : 
percent_ordanance_on_target, percent_target_destroyed, bda_comment, unit_supported) 

IMMEDIATE_REQUESTS {immediate _air_request_number : unit_supported) 

RECON_TARGET {location : target_length, target_width) 

COMPRISES {ato_start, ato_stop, air_tasking_code, mission jtumber, alcjcallsign :) 
CONTROLS {missionjiumber , alcjcallsign, callsign :) 

REQUESTS {immediate _air_request jmmber, missionjiumber, alcjallsign :) 
INTERESTJN {request jmmber : location) 

MAY_DESIGNATE {alcjallsign, missionjiumber, pointjumber :) 

UPDATES {atojtart, atojtop, airjaskingjode, missionjiumber :) 

REFUELS {alcjallsign, request jmmber : mission_number) 

COMMUNICATION_DATA {callsign : control_agency, primary_frequency, 
secondary _frequency) 

REPORT-IN_POINTS {control jgency : control_point) 

RECEIVING_AIRCRAFT {missionjiumber, alcjallsign : number_of_aircraft, aircraft_type, 
amount_of_fuel, refueling time) 

FUEL_REQUIREMENTS {number jfjir craft, amount jf Juel : fuel_requirements) 
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REQ_LOCATION {request number : location_type, location) 

REQ_STATUS (missionjtumber, a/c_callsign, request jiumber : altitude, mission_comment) 

MSN_STATUS {mission jiumber, alc_callsign, request jtumber :) 

A/C_STATUS {mission Jiumber, alcjaflsign : alert_status, primary_configuration_code, 
secondary _configuration_code, iff/sif_codes, est_time_airbome, est_time_of_retum) 

A/C_WEAPONS {alcjallsign : number_of_aircraft, aircraft_type) 

MSN_TYPE {mission Jiumber : mission_type) 

TGT_MSN {target jdentifier, mission jiumber, alcjallsign, request jumber :) 

TGT_DATA {target_identifier : time-on-target, time-off-target, target_type, location, 
target_comments ) 

TGT-TTME {tar get jdentifier , time-on-target, time-off-target ;) 

TGT-ID_LOCN {tar get jdentifier : location) 

RECON_REQUEST {request jiumber : priority, mission_start, mission_stop, 
latest_time_info_of_value, mission_type, coverage_type) 
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Normalized Relational Schema File Format 



AIR_TASKING_ORDER 3 3 

ATO.START C,7 

ATO_STOP C,7 

AIR_TASKING_CODE C,43 

ROUTE 5 2 

MISSION_NUMBER C,8 

POINT_NUMBER N,2 

CONTROL_POINT_TYPE C,3 

LOCATION C,20 

ARRIVAL.TIME C,7 

RIO.LOGS 3 1 

MISSION_NUMBER C,8 

ACTUAL_TIME_OF_ARRIVAL N,4 

ACTUAL_TIME_OF_RETURN N,4 

BATTLE_DAMAGE_ASSESSMENT 7 3 

LOCATION C,20 

TIME-ON-TARGET C,7 

TIME-OFF-TARGET C,7 

PERCENT_ORDANANCE_ON_TARGET N,2 
PERCENT_TARGET_DESTROYED N,2 

BDA_COMMENT C,30 

UNrr_SUPPORTED C,9 

IMMEDIATE_REQUESTS 2 I 

IMMEDIATE_AIR_REQUEST_NUMBER C,5 
UNIT_SUPPORTED C,9 

RECON_TARGET 3 I 

LOCATION C,20 

TARGET_LENGTH C,7 

TARGET_WIDTH C,7 

COMPRISES 5 5 

ATO_START C,7 

ATO_STOP C,7 

AIR_TASKING_CODE C,43 

MISSION_NUMBER C,8 

A/C_CALLSIGN C,I2 
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CONTROLS 3 3 

MISSION_NUMBER C,8 

A/C_CALLSIGN C,12 

CALLSIGN C,15 

REQUESTS 3 3 

IMMEDIATE_AIR_REQUEST_NUMBER C,5 
MISSION_NUMBER C,8 

A/C_CALLSIGN C,12 

INTEREST_IN 2 1 

REQUEST_NUMBER C,6 

LOCATION C,20 

MAY_DESIGNATE 3 3 

A/C_CALLSIGN C,12 

MISSION_NUMBER C,8 

POINT_NUMBER N,2 

UPDATES 4 4 

ATO_START C,7 

ATO_STOP C,7 

AIR_TASKING_CODE C,43 

MISSION_NUMBER C,8 

REFUELS 3 2 

A/C_CALLSIGN C,12 

REQUEST_NUMBER C,6 

MISSION_NUMBER C,8 

COMMUNICATION_DATA 4 1 

CALLSIGN C,15 

CONTROL_AGENCY C,4 

PRIMARY_FREQUENCY C,8 

SECONDARY_FREQUENCY C,8 

REPORT-IN_POINTS 2 1 

CONTROL. AGENCY C,4 

CONTROL.POINT C,20 
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RECEIVING_AIRCRAFT 6 2 


MISSION_NUMBER 


C,8 


A/C_CALLSIGN 


C,12 


NUMBER_OF_AIRCRAFT 


N,2 


AIRCRAFT_TYPE 


C,6 


AMOUNT_OF_FUEL 


N,4 


REFUELING_TIME 


C,7 


FUEL_REQUIREMENTS 3 2 


NUMBER_OF_AIRCRAFT 


N,2 


AMOUNT_OF_FUEL 


N,4 


FUEL_REQUIREMENTS 


N,4 


REQ_LOCATION 3 1 


REQUEST_NUMBER 


C,6 


LOCATION_TYPE 


C,6 


LOCATION 


C,20 



REQ_STATUS 5 3 

MISSION.NUMBER 

A/C_CALLSIGN 

REQUEST_NUMBER 

ALTITUDE 

MISSION_COMMENT 



MSN.STATUS 3 3 

MISSION_NUMBER C,8 

A/C_CALLSIGN C,12 

REQUEST_NUMBER C,6 

A/C_STATUS 8 2 

MISSION_NUMBER C,8 

A/C_CALLSIGN C,12 

ALERT_STATUS C,3 

PRIMARY_CONnGURATION_CODE C,5 
SECONDARY_CONnGURATION_CODE C,5 
IFF/SIF_CODES C,5 

EST_TIME_AIRBORNE N,4 

EST_TIME_OF_RETURN N,4 



C,8 

C,12 

C,6 

C,5 

C,22 
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A/C_WEAPONS 3 1 

A/C_C ALLSIGN C,12 

NUMBER_OF_AIRCRAFT N,2 

AIRCRAFT_TYPE C,6 

MSN_TYPE 2 1 

MISSION_NUMBER C,8 

MISSION_TYPE C,5 

TGT_MSN 4 4 

TARGETJDENTinER C,20 

MISSION_NUMBER C,8 

A/C_C ALLSIGN C,12 

REQUEST_NUMBER C,6 

TGT_DATA 6 1 

TARGET_IDENTIFIER C,20 

TIME-ON-TARGET C,7 

TIME-OFF-TARGET C,7 

TARGET_TYPE C,6 

LOCATION C,20 

TARGET_COMMENTS C,35 

TGT-TIME 3 3 

TARGETJDENTIFIER C,20 

TIME-ON-TARGET C,7 

TIME-OFF-TARGET C,7 

TGT-ID_LOCN 2 1 

TARGET_IDENnFIER C,20 

LOCATION C,20 

RECON_REQUEST 7 1 

REQUEST_NUMBER C,6 

PRIORITY C,1 

MISSION_START C,7 

MISSION_STOP C,7 

LATEST_TIME_INFO_OF_YALUE C,ll 

MISSION_TYPE C,5 

COVERAGE_TYPE C,7 
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APPENDIX H: dBASE IV REPORTS 



Retrieving information in dBASE IV is accomplished through queries. Queries generate 
views of the database to meet the user and application requirements. Views are virtual 
databases, logical, not physical structures. Views allow: 

•• data to be seen in different ways without physical duplication 

* manipulation of data without changing original database 

' database security 

* users to be shielded from changes in the physical database 

The query generated views are used by user for "on the fly" manipulation of data, or by the 
application for report and form generation. Tables are linked to one another in the DASC 
database through queries, and views, forms, and reports developed using these multiple tables. 
The following examples show the capabilities of the DASC application: 

* Report-In/Out Log view that links multiple tables 

* BDA update form for data insertion of BDA data 

- Immediate Air Support Report that lists immediate air support requests received, 
supported unit, mission assignment and BDA 

* Report-In/Out Log Report 
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Organize Fields Go To Exit 



REPORT-IN/OUT LOG VIEW 





CJ O O U CJ 


< 


Q < < < Q < < 
w hj J iJ w 1-3 1-3 


u 


CEj CO CQ P3 CO CO 




in o o o o in 




rT n m O O H 




r) in in o o ^ 


< 


rH rH iH iH rH rH 




o in o o in o 




m ^ o o H r> 




m in in H o m 




rH rH rH rH rH rH 




o o in in in o 


< 


o m ^ ^ o 


Eh 


r) ^ CN 00 CO ro 


< 


rH rH rH rH 




o o o o o in O 


< 


o r> o r) o o 


Eh 


<NJ ^ (N H CO nj 


W 


rH rH rH rH O O rH 


O 




H 




U, 








o 




o 


H H (N (N 


o 


O O O O 


M 


O O O O 


CO 


< < < < 


a 




H 












o 


CM CM 


o 


CO CO H H 


H 


W iad o o 


cc; 


S S o o 


04 


VD VO C < 


w 


CO CO o 


04 


H H r> VO ^ 3: 




1 ^ I rH ^ rH rH 


H 


< i < 1 I I 1 


o 


\0 XXX 


< 


^ X o o < 


o 


CM H (N H VO CM CM 








n 




t< v£> 

S 




H < in r' w w 




K (N U O 




a a PS < < 
W H W W Eh Cn 


CO 


ffi j Q w cr cr 
1-^ O J H O ^ ^ 


1 


H H H <; ffi o o 


o 


« a « « o CO w 




H r> in n- CM ^ VO 
o o o o o o o 


o 


o o o o o o o 


:z: 


o o o o o o o 




X X X 


CO 


o o o o o o ro 




m ro m fo r> r) CM 



122 



Browse || F: \dbsample\RIOVIEW ||Rec 1/7 ||view || Readonly 1| Num 



BDA UPDATE FORM (empty) 



BDA UPDATE FORM 



LOCN 






TOT 


TFT 




ORD_ON_TGT 


0 TGT_DEST 


0 


BDACMNT 

SUPPORTED 







BDA UPDATE FORM (complete) 



BDA UPDATE FORM 

LOCN 32SMV1234512345 

TOT 301300Z TFT 301310Z 

ORD_ON_TGT 50 TGT_DEST 50 
BDACMNT 

2 TANKS DESTROYED 
SUPPORTED 3/1 
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IMMEDIATE AIR SUPPORT SUMMARY REPORT 



Page No. 1 IMMEDIATE AIR SUPPORT SUMMARY 



IMMEDIATE 


SUPPORTED 


MSNNO 


BDA 


BDA COMMENT 


30-01 


3/1 


30F0001 


50/50 


2 TANKS DESTROYED 


30-03 


3/1 


30H0006 


90/90 


DESTROYED VEHICLE 



REPORT-IN/OUT LOG REPORT 



Page No. 1 REPORT-IN/OUT LOG 

11/25/91 ================= 
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NO 
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